19 March 2011

Tightening the Definition of SaaS and Cloud

I've recently been exposed to two vendors offering "cloud" and "SaaS" options to replace two in-house legacy enterprise/corporate (not customer facing production) systems.

In this process, I connected some mental dots that there are really a few flavors of SaaS, and the distinction is quite important with respect to enterprise architecture.

The two service offerings can be roughly thought of in this way:
  • The offerings were touted as SaaS and cloud
  • New software that is better than our current in-house legacy systems (regardless of whether we host or they are "in the cloud")
  • The software is hosted by the software provider, unknown what type of "cloud" IaaS is under that provider, if any (perhaps just virtualization in their own DC).
  • The software instance is spun up by the provider specifically for us.  It is a copy of the software, dedicated to us.
  • The software can be extended a lot - add-on modules can be activated through configuration changes, bespoke modules/code can be added.  Kinda-sorta like a pick-and-mix or evolving PaaS model
  • Software upgrades must be rolled out with associated consideration of any bespoke changes that have been made.
  • Security restricted to only be available within your corporate intranet
  • Flat monthly rate per user charging model with volume (# of users) price breaks
As the two service reviews went on, the dots finally connected, and I realized I had been *marketed* too more effectively than I'd like to admit.

The above isn't "cloud" or SaaS, at least not with the definition I'm going to take here.  It is actually a hosted managed service offering (MSP or ASP).  At best it's a halfway-house to cloud and SaaS.  All you've really done with this approach is shift some techops and infrastructure responsibilities from in-house to the service provider and reduced your in-house economies of scale (assuming you have to maintain those skills).

For something to be a cloud/SaaS offering in my terms, here is what it needs to be:
  • Public Internet facing
  • One centralized installation shared by many customers
    • Powering the service is an IaaS
    • Can quickly scale up/down with virtually no cost to make the change (costs changing proportional to increased/decreased usage)
    • Horizontal fault tolerance design (HW redundancy becomes irrelevant)
  • Focused offering
    • Service addresses a specific functional requirement, it isn't an omnibus offering
    • Vibrant user community making suggestions of how to improve the product
    • Quick time to market for new features
    • Strong product management and vision
  • Product improvements put live appear immediately for all customers
    • One exception: "beta" version may be option in by the customer, but certainly under the customer, not vendor, control  
    • No rolling upgrades for each customer once a new release is ready
  • A complete set of APIs ("API as a storefront")
    • Almost all functionality available via the application is available via API
    • Well documented
    • Hardened (API security, rate limits, et al)
    • Ready for mash-up integration with other focused offerings
  • Usage based billing
    • Proportional to amount of computation, storage, and connectivity you use (IaaS transparency)
    • Additionally factoring in the value of the SaaS itself
    • No billing related to seats, users, or CPU cores
In noting the difference between the two, I'm not advocating one or the other.  The choice of course depends on circumstances and strategy.  I'm also making no effort to address the common enterprise concerns of cloud such as security, data ownership, and business continuity.  However, I do have a very strong view which way the IT world is going and given the choice, I know which I'd select.

18 March 2011

Conclusions from Betfair's Outage

Niall Wass and Tony McAlister of betfair recently published a summary of betfair's 6 hour outage on 12 March 2011.  What follows is a review of their analysis.

Most of betfair's customers will have no idea what Niall and Tony are talking about.  "This [policy] should give maximum stability throughout a busy week that includes the Cheltenham Festival, cricket World Cup and Champions League football" is about the only non-tech part of the article that their customers can relate to.  However, for us technologists, the post provides some tasty detail for us to learn from other's mistakes.

The post is consistent with a growing and positive trend of tech oriented companies disclosing at least some technical detail of what happens to cause failures and what is to be done about it in the future.  Some benefits from this approach:
1. Apologize to your customers if you mess them about - always a good thing to do when you mess them about (Easyjet or Ryan Air - I hope you're reading this).  Even better is to offer your customers a treat - unfortunately betfair only alluded to one and didn't provide concrete commitment.
2. Give public sector analysts some confidence that this publicly traded company isn't about to capsize with technical problems
3. Receive broad review and possibly feedback about the failure.  Give specialist suppliers a chance to pitch to help out in potentially new and creative ways.
4. As a way to drive internal strategy and funding processes in a direction they otherwise might not be moving.

Level of change tends to be inversely proportional to stability.  "In a normal week we make at least 15 changes to the Betfair website…".   This is a powerful lesson that many non-tech people do not understand - the more you shove change into a system, the more you tend to decrease it's stability.  This statement also tips us that betfair has not adopted more progressive devops and continuous delivery trends to more safely pushing change into production.  

The change control thinking continues with "… but we have resolved not to release any new products or features for the next seven days".  This is absolutely the right thing to do when you're having stability issues.  Shut down the change pipeline immediately to anything other than highly targeted stability improvements.  Make no delivery of new features a "benefit" to the customer (improved stability) and send a hard statement to noisy internal product managers to take a deep breath and come back next week to push their agenda.

Although betfair might not be up on their devops and continuous delivery, they have followed the recent Internet services trend of being able to selectively shut down aspects of their service to preserve other aspects:
- "we determined that we needed our website 'available' but with betting disallowed"
- "in an attempt to quickly shed load, we triggered a process to disable some of the computationally intensive features on the site"
- "several operational protections in place to limit these types of changes during peak load"

Selective service shutdown is positive, it hints that:
1. The architecture is at least somewhat component based and loosely coupled.
2. There is a strategy to prioritize and switch off services under system duress

The assertion that betfair spent several hours verifying stability before opening the site to the public suggests bravery under fire.  "We recovered the site internally around 18:00 and re-enabled betting as of 20:00 once we were certain it was stable".  There must have been intense business pressure to resume earning money once it appeared the problem was solved.  However, during a major event, you want to make sure you're back to a stable state before you reopen your services.  A system can be in a delicate state when it is first opened back up to public load levels (e.g., page, code and data reload burden) which is one reason why we still like to perform system maintenance during low use hours so that the opening doors customer slam when the website/service opens are at least minimized.

The crux of the issue appears to be around content management, particularly web page publication.  Publishing content is tricky as there are two conditions that should be thoughtfully considered:
- Content being served while it is changing which results in "occasional broken pages caused by serving content" and here-and-gone content where content has been pushed to one server, but not another
- Inconsistency between related pieces of content (e.g., a promotional link on one page pointing to a new promotion page that hasn't been published yet)

It appears that betfair's content management system (CMS) is not async nor real time: "Every 15 minutes, an automated process was publishing…".  Any time a system is designed with hard time dependencies is a timebomb waiting to go off, with the trigger being increasing load: "Yesterday we hit a tipping point as the web servers reached a point where it was taking longer than 15 minutes to complete their update".  A lack of thread safe design is another indicator of a lack of async design that tends to enforce thread safety: "servers weren't thread-safe on certain types of content changes".  A batch, rather than on-demand approach is also symptomatic of the same design problem: "Unfortunately, the way this was done triggered a complete recompile of every page on our site, for every user, in every locale".  Therefore likely not an async on-demand pull model but rather a batch publish model.

The post concludes with a statement of what has been done to make sure the problem doesn't happen again:
1. "We've disabled the original automated job and rebuilt it to update content safely" - given the above design issues, while thread safety may have been addressed, until they address the fundamental synchronous design, I'd guess there will likely be other issues with it in the future.
2. "We've tripled the capacity of our web server farm to spread our load even more thinly" - hey, if you've got the money in the bank to do this, excellent.  However, it probably points to an underlying lack of capacity planning capability.  And of course, everyone one of those web servers depends on other services (app server, caches, databases, network, storage, …) - what have you done to those services by tripling demand on them?  Lots of spare capacity is great to have, but can potentially hide engineering problems.
3. "We've fixed our process for disabling features so that we won't make things worse."
4. "We've updated our operational processes and introduced a whole new raft of monitoring to spot this type of issue." - tuning monitoring, alerting, and trending system(s) after an event like this is crucial
5. "We've also isolated the underlying web server issue so that we can change our content at will without triggering the switch to single-threading"

And here are my lessons reminded and learned from the post:
- If you're having a serious problem, stop all changes that don't have to do with fixing the problem
- Selective (de)activation of loosely coupled and component services is a vital feature and design approach
- Make sure the systems are stable and strong after an event before you open the public floodgates
- Synchronous and timer based design approaches are intrinsically dangerous, especially if you're growing quickly
- Capacity planning is important, best done regularly, incrementally and organically (like most things), not in huge bangs.  One huge bang now can cause others in the future.
- Having lots of spare capacity allows you avoid problems… for awhile.  Spare capacity doesn't fix architectural issues, just delays their appearance.
- Technology is hard and technology at scale is really hard!

Niall and Tony, thanks for giving us the opportunity to learn from what happened at betfair.

05 March 2011

The Trial Environment - Innovation Infrastructure with an Enterprise wrapper


A "trial" environment is a high risk production environment that sits within a low risk Enterprise environment.

Circumstances that might drive you to set up a trial environment:
  • Business has revenues derived from enterprise production systems it wants to protect through risk management, but...
  • Business wants to move fast and be innovative, and...
  • Business wants to work with third parties, some of which are "two-guys-and-a-dog" start-ups who can't afford to focus on making their systems enterprise friendly.
The trial environment helps a technical team to balance these potentially conflicting requirements and deliver both risk- managed and risk-embracing services into the business.

(NB: Like most articles on this blog, the trial environment was conceived within a context of internet delivery systems and online gambling.  Please keep that context in mind as you read.)


But why would a production IT service want to enable lunatic startup companies and me-me-me product managers into a carefully risk managed production environment?

One reason is to foster innovation.  New innovative products tend to focus on the core features and not the "-ilities" such as scalability, stability, and security.  The new product team shouldn't be spending time on having to specify and justify a large enterprise environment when there are crucial features to be coded.  If we can provide infrastructure and costs that play by the same rules as cheeky little start-ups, we can limit their ability to end-run us.

Another reason is that from a business case perspective there is no reason to spend on big expensive kit to meet fanciful revenue forecasts.  It's much better to trend off of real data and provide an environment that can scale to a medium level quickly.

But mostly it's just nice to be able to say "yes"when the panicked bizdev guy comes over to you in desperation so he can close a deal tomorrow as opposed to "that will take 6 sign-offs, 3 months to order the kit, and will cost £400,000."  Operational process and cost intensity should match as closely as possible to revenue upsides and product complexity.

The Business Owners Point of View

How the trial environment is presented to the business, perhaps product managers, that have to pay for it:
  • Suitable for working with small, entrepreneurial, and/or external companies/teams
  • You can move quickly with it
  • Fewer sign-offs, less paperwork
  • Cheap (after a base environment is set up)
  • Enables you to focus on initial product bring-up and delivery and not overspend on an unproven product.
  • It's billed back to your project as you use it so no big up-front costs; if you're project stops, we don't have left over dead kit
  • Suitable for lower concurrent users and transaction volumes
  • Good for proof of concept projects - if project not signed off, no big capital investment
  • More risky (less stable, scalable, secure) than our enterprise environment
  • Your first point of contact if there are technical problems is the small entrepreneurial company you're working with and not IT support
  • Not particularly secure
  • Not PCI/DSS friendly (so don't store related data or encode related processes in trial)
  • Only small to medium sized products can use trial - we only have so much capacity standing by
  • If there is a failure in the trial environment, it will generally be the responsibility of the third party to fix it.  We won't know much about it.  We'll only take care of power, connectivity and hardware.
  • At a practical level, a failure in the trial environment might mean several days of downtime
  • If your revenue goes up for a product running from trial, we recommend it's moved it from trial to enterprise.  That will be your call for you to manage your revenue risks.
  • A new product that is failing will still accrue operational costs.  Pull the plug if you need to and with trial shutting down a member environment is trivial.
What happens if things take off for a product in the trial environment?  It's up to the small team or company the product manager is working with to identify this and initiate a project to "enterprise" their product.

From the Entrepreneurial Point of View

How the trial environment is offered as a production option to small, entrepreneurial, and/or external companies or teams:
  • We'll give you an infrastructure that you're comfortable working with that doesn't have the usual enterprise computing overheads
  • We'll take responsibility for deploying and fixing the hardware, power, and connectivity - everything else is yours.
  • Quickly receive 1 or servers you need to get your product going - no paperwork and waiting around for kit to show up
  • We only have a few types of servers on offer - likely a "small" one for web/app servers and a "big" one for a database server.  We'll recommend some options if you're not sure what you need.  The servers are not redundant, fault-tolerant kit.  If you want that in trial, you'll need to build it into your application.
  • Tell us what OS you want. We have 3 standard OSs (Linux, Solaris, and, maybe Windows) and if you want something else it's going to be more difficult for everyone.
  • Tell us how much storage you need.  You'll get a little bit local on the server and a flexible capacity will be mounted on your server.  The flexible capacity can grow over time without any retooling or paperwork.
  • Tell us how much network capacity you'll need.  We'll QoS at that level.  Maybe no bursting allowed.
  • Your servers will be on their own subnet, just one flat LAN for everything.  No DMZ, multi layer firewalls.
  • You get a firewall in front of you with, tell us what inbound and outbound ports you want open for each server you request.  80, 443, and 22 are easy for us, everything else will make us raise an eyebrow.
  • Beyond simple firewalling, you manage your own security, e.g.,  locking down ports/services and OS patching
  • No content switch.  They're expensive and you're clever enough to use Apache to figure that out I'm sure.
  • Put your own monitoring in place, we're not going to watch it for you.  If you need to go from a "small" to "large" server or need more servers, you'll need to let us know.
  • Put your own backups in place.  Specify some flexible storage for them on one of the servers.  We won't be backing up anything.
  • All change control sits with you.  We have no oversight.
  • No remote hands provision is expected to be required.
  • If you're doing anything that affects production or other members of trial you're servers will be powered down immediately.
The Production Operations Team Point of View

How the trial environment is managed by the production operations team:
  • Beneath the edge network, the trial environment is on hardware fully separate and distinct from production.
  • Production operations owns and is responsible for the hardware, network, and power - both initial and on-going.  We provision a base OS and hand over the keys to the product team.  That's it.
  • Fairly generous SLA on responding to HW, network, power failures reported to production support.
  • The trial environment is ideally implemented with some type of in-house cloud service and/or VMWare.  If that's not possible, you'll have to manage by-box inventory so that you always have a few unused boxes of each type ready to commission.  Must keep a stand-by inventory ready to go.  Effective maintenance of slack and procurement to backfill is essential.
  • Create two server types, small and large.  Decide on cores, memory, disk space for each.  You will need to change this view over time, so re-evaluate it every 6-12 months.
  • Establish maybe 3 standard OS installs.  We don't own patching or securing the OS.
  • Use a SAN to enable flexible filesystem provisioning
  • Fixed maximum allocation of internet bandwidth for all members of trial, then fixed allocation to each member.  No trial member should be able to stomp on other trial members or anything in production.  QoS implemented.  Bursting is debatable.
  • Dedicated edge firewall.
  • Network to enable multiple subnets for each different user of trial.  Each user of trial can generally only see only their own network and servers.  Holes/routing between subnets and between enterprise and trial subnets may be conditionally opened for API (and only API; no e.g. DB) access.
  • No content switch, load balancer
  • No backups
  • No hardware RNG
  • Some Single Points of Failure ok
  • We own firmware updates for hardware
  • We don't monitor or alert on any virtual servers.  We do monitor and alert on underlying hardware, including the network kit and SAN.
  • May use a second tier hosting location for trial kit
  • It might be possible to use older kit being decommissioned from production for the trial environment.  While this would likely increase day-to-day operational costs (heterogenous and older kit), it would bring down initial capital investment in trial.  Also consider used/refurb kit.  Think cheap.
  • Keep a basic overview of trial and its services updated on the intranet.  Make sure all product managers and bizdev types are educated about it.
  • Periodically review trial usage with each business owner.
As the production team evolves the trial environment offer, it's likely that some of the "we don't do this in trial" items above will change as cost effective and lightweight ways are found to deliver them into trial.  Possible examples are backups, more sophisticated networking (load balancer), a provision of fault tolerant disk on server instances, or a shared (between trial members) database instance.

Other Considerations

Some other things to keep in mind to make the trial environment successful:
  • Aspects of production may be accessed via e.g. an API.  This introduces a point of vulnerability to production.  There are good design practices for hardening APIs that are exposed to trial such as logging, monitoring, authentication, rate limiting, and kill switches to protect what is on the production side of the API.
  • It may be cost efficient to spin up a single instance of an expensive service (e.g., Oracle) that can be shared between multiple trial members.  This introduces a fair amount of complexity to manage the DB itself including QoS, security, and change control.
  • The trial environment won't build and run itself for free.  Technical operation staff are required.  The number of staff should be proportional to level of change and size of the environment.
  • If a third party is involved, they must have an internal business representative championing their product or service, someone who understands the product and will champion it regularly.  A bizdevy, bring-the-external-party-in, hurl-over-the-wall-to-IT-ops doesn't work.
  • A product or service typically requires other functional contributions as well:  game platform operations, marketing, account management and sales, handling of amended contracts for the new product, on-going product management to improve the product, and website integration and updates.
  • Trial could also be used to spin up staging or pre-production test environments.

The trial environment can be used to provide a low cost alternative for startup, experimental, speculative, and just plain insane product ideas.  It's a hosting option that edgy product managers and bizdevs will like because of the lightweight commitment and speed of delivery.  Entrepreneurial teams and startups will like it because it'll feel like something they're use to and won't slow them down.  The production support team may feel uncomfortable with it initially because trial violates a lot of "best practices" in production.  But in the long run they'll see how it becomes a business enabler that fosters innovation in a cost effective way.

Good luck and let me know if you manage to establish a trial environment in your shop!

Pesky winmail.dat with Outlook, Apple Mac OS X Mail and me.com IMAP folders

I use me.com's IMAP folders to file email as part of an inbox zero policy I inflict on myself.  I recently had to resume using Exchange 2010 based email, but unfortunately not (yet!) directly connected to Apple Mac OS X Mail.  To access the Exchange mail, I've elected to use Outlook inside a Windows 7 VM.  I then hooked in my me.com IMAP folders into Windows Outlook so the Exchange and me.com folders are side by side in Outlook.  I then added an Outlook rule to copy new email that hits my Exchange Inbox to a me.com's Inbox.

This worked ok until I opened my first message in OS X Mail that had an attachment.  Instead of a normal attachment, I instead found a "winmail.dat" file.  Funny, I'd not seen one of those in a long time.

After some digging, I came across two ways to deal with the winmail.dat attachment problem:

1. The first and not recommended choice is TNEF's Enough.  The price is right at free/donations.  However, it's usability is awkward as you are required to open the *.dat file in a separate application that unpacks the TNEF format file from Exchange/Outlook and gives you the option to save the file.  I tried it, too painful.

2. The second and recommended choice is Letter Opener.  It is between USD 30-50.  It is seamlessly integrated with OS X Mail so you don't ever see a *.dat file, you see the attachments as you would in Outlook.

So if you stumble on this problem and need to consider TNEF's Enough versus Letter Opener, I'd recommend Letter Opener.