Author: bob

Hi Rob,

 This is not important just some points I was thinking about during the team call this morning. You always have an interesting point of view so I thought I’d share and get your feedback.

In particular the discussion about how long AWS would need to survive without another outage in order to create 5x9s availability. It occurred to me that it was a completely fatuous measurement because I believe we’re at that Dev/Ops cross roads where we can no longer depend on hardware to save us from data loss. Looking at the AWS Service Level Agreement it basically states that “we won’t charge you if we can’t provide a service” to quote them directly they say “AWS will use commercially reasonable efforts…” which is not a commitment to service that I’d like to have my salary dependent upon.

Over the past 20 years or so there has been a creeping paradigm of hardware resilience for example RAID on disks, remote replication, clustered failover, hardware error checking and many other such technologies that have allowed developers to ignore resilience in their systems. But in the world of cloud, all of the resilience that has been baked into hardware is now gone. If you don’t own your own datacenter and haven’t ensured resilience and failover capability then, as a developer, you’d better start thinking about it again because your service provider isn’t go put it in, it would make their whole charging model unsupportable.   

There is evidence that developers are already thinking about this and have done something about it. I’m probably not on the bleeding edge of ideas here. For example one of my bug bears with Docker is its lack of state. But in an environment where there isn’t any resilience it makes absolute sense not to preserve any state, if it doesn’t have a state then you can start another session on another piece of hardware anywhere you like with minimal disruption to your applications. Complete statelessness is hard to achieve, so somewhere there has to be some DB which needs hardware resilience.

I think my point really is that we have to fundamentally change our thoughts about the way systems work. Talking about 5x9s resilience is no longer relevant.

Comments, thoughts, ideas?

so I  replied:

Hi Simon

I’m seeing a couple of data points as the market view on public cloud matures.

• It’s not cheaper.
• It’s an opportunity risk

There’s a growing market for tools and professional services for public cloud to help customers constrain their costs.  I was amused to hear that Amazon itself manages a 2^nd hand market on reserved instances (RI’s) where customers can resell their unused RI’s to other AWS customers to recoup some of those costs.  And there are consultancies that help customers either buy those RI’s from the marketplace at the lowest price or sell their RI’s at the highest price.

Seems to conflict with the idea that cloud is cheap.

The opportunity risk piece comes from the fact that organisations can implement products faster with public cloud without going through the CAPEX procurement cycle.  And if those new products or services fail then they aren’t left with infrastructure they don’t need.  So cloud isn’t a cheaper way to deliver infrastructure.  But a faster way to deliver it in the short term.

How is that related to your point above?  I think it’s examples of how the perception of public cloud is changing.  I personally like to take the long view.  When TV’s were first introduced they would be the death knell for the cinema.  When the internet came around it would be the end for books and newspapers.  The introduction of new technology always predicts the supercedence of existing tools.  Don’t get me wrong; CD’s are no more  (although interestingly vinyl lives on), and newspapers are in a dwindling market.  But the cinema experience is fundamentally different to the TV experience.  The book experience is different to reading websites. 

Those examples show that different technologies enable us to consuming things in different ways.  There’s no doubt the x86 server market is in decline.  But that’s from a position where 100% of technology is on premises.  As we learn more about the benefits of public cloud we learn that it also has drawbacks in the way it’s been implemented.  I therefore believe that a balance will be found where some workloads will necessitate being within a customer’s physical location.  And some will benefit from being hosted with a hyper-scale cloud provider. IT will be consumed in a different way.  I don’t believe on-premises infrastructure will go away though.

I childishly take some glee from AWS outages.  I take umbrage from the assertion that Infrastructure is irrelevant and the developer is the new king maker.  Software Development is hard.  Infrastructure is hard.  So when AWS or Azure or AWS (again) has an outage it brings that reality into stark relief.  The glee I get is from the humble pie being eaten by so called pundits who portray cloud as the next evolution of technology when really it’s the emperor’s new clothes.  It’s somewhat unfair to expect developers to be experts in how to make their code run efficiently, be well documented, modular, deliver services to market quickly – and then also be experts on high availability, disaster recovery, data lifecycle management, etc. etc. etc.  Both skills are important.  But are fundamentally different.  To expect public cloud to be able to deliver the same service without the same level of expertise is patently ridiculous.  It won’t achieve 5x9s.  But then I don’t believe it should.  It’s something different.  And should be architected and understood as such.

Tying the various threads together, I strongly believe there is a use case for agile, devops style methodologies.  And an agile infrastructure to support it.  But I firmly believe that one size doesn’t fit all and infrastructure architects and expertise has a strong role to play in conjunction with software development expertise to deliver the right solutions for the future.

Well that was a long winded response.  I can see a copy and paste blog post coming J

A question from a colleague– do I think everything will go containers?  Our conversation kind of got lost in a conversation around devops and version control.  But we had a good and healthy debate

To try and answer his question , my view is that Containers are a solution to two problems:

• It’s a business problem experienced by startups in silicon valley who need to iterate functionality quickly.  With a small team they need to get something to market and then keep adding new functionality quickly.  So it’s solving a business problem around small teams, speed to market and the ability to pivot based on a rapidly changing market requirement and competition (uber vs lyft for example).  Containers are a way of supporting that microservices type architecture to facilitate a devops / minimum viable product / continuous integration approach.  Other existing technologies don’t support that requirement as well as containers.
• It’s a technology problem experienced by guys who are using public cloud wherein the infrastructure is typically crap and unreliable.  So the ability to quickly deploy lots of copies of your app enables you to mitigate that crap infrastructure.  Application portability is a problem that legacy technology platforms don’t really answer very well (hard coded / embedded IP addresses say “hi”)

For those problems, containers are great.  But that’s not every use case.  Banks selling mortgages is a relatively static requirement, heavily regulated.  The bank may take on more mortgages but they don’t have the need to iterate quickly.  That requirement is to have an architecture that supports speed, resiliency and high data processing.  Walmart might need to iterate quickly to get an app to market to differentiate against Target.  But the core requirement to take payments for products in store and for the sale of product to be reflected in the stock replenishment system is a static requirement.

For the benefits they bring, they will bring other problems (integration into existing monitoring dashboards for performance, errors, etc is a massive ops issue that devs don’t consider for example).  If an organization can see past wanted to use the latest shiny thing and can match an infrastructure + software solution to their actually need –  I don’t see containers replacing everything.

But then maybe I’m an out of date old guy.

Cloud cloud cloud umm what?

There are so many cloud options today it can be baffling.  So over the next few pages were going to try and break it down a bit to explain what the different options are, and help with the decision process for each option.

Infrastructure as a service (IaaS)

IaaS is typically subdivided into two clear components; Private Cloud and Public Cloud.  We have an overview of IaaS and Private Cloud here.

The elevator pitch is Infrastructure as a Service enables the automatic provisioning of operating systems onto physical or virtual hardware by Orchestration Software.  Private Cloud uses infrastructure within an organisations data centre.  Public cloud uses the infrastructure in a provider’s data centre.  And Hybrid Cloud deploys some systems locally, and some in the public cloud.  Decisions on location will be driven by internal security policies, external regulations and technology constraints such as application latency requirements

IaaS also provides the option of self-service allowing users to request their own infrastructure without IT admins lifting a finger.  And it has the option to charge back individual business units or cost centres for what they are using

The key benefit of cloud technologies is around doing things in a new and different way.  Being blunt, Infrastructure as a Service is the lowest common denominator.  It lets you do the stuff you’ve always done in more efficient and flexible ways.  However as our intro to Infrastructure as a Service highlights, cloud isn’t just a technology change but a people and process change as well.  As such it has other benefits in terms of getting an organisation better prepared for the other cloud options.

Platform as a service (PaaS)

Here the provider will provide additional components on top of the operating system.  So for example Azure has Azure websites and Azure Cloud Services.  Here you don’t need to install the Web Server role into IIS.  All you need to do is create your code and Microsoft does the rest.  The flipside of this is that Microsoft specify what they support.  The supported languages for Azure Websites are .Net, Java, PHP Node.JS and Python.  Want to code in Perl?  Ruby?  Go?  You’re out of luck. You’re also restricted by the versions of languages supported

But that’s not necessarily a bad thing.  It lets developers focus on developing code and removes the concerns about scaling infrastructure, patching infrastructure and software and lets things happen faster with less intervention

Software as a service (SaaS)

SaaS is the last model for Cloud.  Here all your paying for is a license to use the software.  That usually (but not exclusively) means accessing that software through a web browser.  Typically cited examples are Salesforce.com, Gmail, Dropbox, etc.  Here you have a generic service that’s the same for everybody.  Good candidates for SaaS are functions where your company adds no value.  Salesforce is a great example here because the CRM functions within organisations aren’t where they add value.  Managing sales, managing customers, that’s a relatively generic process.  By selecting SaaS products organisations are able to focus their IT resources on the activities

Which one do I want

In this diagram you have the components of an IT system.

It’s very high level but you can see

• Facilities – the building your equipment is hosted in
• The racks, power, cooling and supporting networking infrastructure the server needs
• The server itself
• The operating system
• The software
• Users accessing that software

Each of those components has a cost associated with it’s complexity.  Remember back to the SaaS description where the use case for SaaS is to pick something generic that isn’t unique to your organisation?  That’s the key decision point as to how you should host your technology.  Infrastructure as a service sounds like a low rent commodity option.  However there may well be unique parts of the product your organisation sells that won’t fit neatly into a Platform as a Service model.  It need specific coding languages, specific configuration on the server to deliver whatever it does.  The further up stack you go, the more personalisation you lose.  Conceptually the technology products that are unique to your organisation are probably better suited to IaaS.  Systems you need to keep your business going but are something everyone uses (email, CRM, etc) are better options for SaaS.  And PaaS sits somewhere in the middle.

Also think about the industry sector you work in.  There may be regulations about where you host your data so checking out where the cloud provider has their datacentre’s is important.  Or more likely that becomes a decision point on whether to go public or private cloud.

Investigate application complexity.  If a legacy application has been coded with the expectation it’s on a high speed LAN, then moving the servers out onto the internet probably isn’t a good idea.

Summary

Hopefully now you’ve got a better idea of what the different cloud technologies are and which might be suitable for your workloads.  There isn’t a one size fits all and a lot of the decisions still require judgement.  However you’ve got the guidelines here on how things work and that should influence your thinking on how you start planning the deployment of your systems going forward.

Remember, the cloud is just someone else’s computer.