Category: cloud

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

Language	Versions
.net framework	3.5		4.5
PHP	5.3	5.4		5.5
Java	1.7.0.51
Python	2.7.3		3.4

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.

Private Clouds – Overview

IaaS or Infrastructure as a Service enables the provision of Infrastructure at the click of a button.  When most people talk about cloud they mean public cloud, and they mean Infrastructure as a Service.  However this doesn’t just need to be done by a cloud service provider like Amazon or Microsoft.  You can replicate the same service on the infrastructure in your data centre by building your own private cloud.

You can get the cloud definitions in the NIST document.  This is what Azure, Openstack, etc are offering with their cloud platforms

With a platform like this you can create applications that understand the infrastructure.  You can use API’s to custom write applications to use the computing nodes, object storage, etc. in a way that wasn’t previously available.  The decision on cloud platform is critical here because for the most part the API’s aren’t portable.  (not strictly true but more or less true)

Exciting stuff.  But lets take a breather and a reality check.  Most enterprises aren’t doing this.  Whizzy media companies or organisations on the bleeding edge of technology are trying this.  Most organisations are provisioning standard VM’s in the cloud with their existing legacy software.  It isn’t the new technology that gets them excited.  It’s the speed of infrastructure provision and the ability to move to a pay per use model that gets people interested.

 

 

What does a Private Cloud look like?

Lets take a look at how IaaS works within the Enterprise Datacentre

You can see in the image that everything is performed using Orchestration software.  There are lots of options available; HP’s Cloud Service Automation, Microsoft’s System Center 2012 Orchestrator or vCloud Director from VMWare.  The Orchestration tool (also known as Automation software) will use standard API’s to run scripts that allocate physical or virtual hardware, and then provision an operating system.  And part of that build will also provision the right agents into the OS for backup, monitoring, etc.

Standardisation is a must for IaaS

The key to technology delivery is not just the technology but the people as well.  For automation software to be effective then your organisation will need to agree a few standard builds.  If there is a different OS build for every application or system then there’s no point trying to automate it.  You’ll spend more time orchestrating the different components than it would take to provision things by hand.  Amazon’s AWS public cloud provides a specific set of template builds –

 

Model	vCPU	Mem (GiB)	SSD Storage  (GB)
c3.large	2	3.75	2 x 16
c3.xlarge	4	7.5	2 x 40
c3.2xlarge	8	15	2 x 80
c3.4xlarge	16	30	2 x 160
c3.8xlarge	32	60	2 x 320

 

You will need to do the same if you are trying to provide a private cloud for IaaS in your organisation.

To move from IaaS to PaaS then you’ll want to start overlaying software on top.  This becomes more difficult because the server guys are asking the software admins (DBA’s, etc.) to relinquish control of their installations and decide on a standard build.

People are much harder to change than technology.

What sort of service are you offering?

The “as a Service” terms gets bandied about a lot without thought about what the description actually means.

When a customer pays for a service, they don’t care about this bits and bogs, the cogs in the machine, they are just paying for the outcome.  Also consider that when you pay for any kind of service you are sacrificing choice for convenience.  For example if you choose a company car instead of taking the car allowance you get free insurance, free tax, free servicing, free consumable parts (like tyres), etc.  But you are constrained by the cars that are available.  You usually can’t choose any kind of make / model and customise your car.  You have to choose the specific cars that have been made available through the service.  The same happens in IaaS – you will make some specific operating system builds and they will always be used.  Choice is sacrificed for convenience.

In building a private cloud, the IT team is also changing what they do for the business.  In the old model you are keeping a server up and running.  When you move to an “as a Service” model, you are now offering a service.  What does that mean?  How quick / responsive will the service be?  What does it offer – High Availability / DR/ etc?  How much downtime will happen with this service?  Descriptions of things are important because the infer meaning.  By calling something a service, the IT department needs to have a good think about what they are actually offering.

How will people use your service?

Part of the sales pitch around Private Cloud / IaaS is the self service automation and chargeback.  The idea is your “customers” (i.e. people in other departments) will log into a portal and request a new operating system

This approval then gets routed through to an IT person or a finance person for approval and once approved then the software will provision the infrastructure.  Part of that build process will also have a duration on it.  Development environments are notorious for never getting removed once they are provisioned.  By provisioning items through a portal, the request can have a time limit on it which comes in as part of the approval.  Once the environment isn’t used anymore then it will get torn down.  In the mean time the project or department is getting billed appropriately for the IT resources they are using

Sounds neat.

In reality what a lot of IT departments are doing is making the portal only available to themselves.  Capacity planning is typically an immature process in many organisations.  So there’s a nervousness around letting anyone in the organisation request infrastructure willy nilly without IT oversight.

The second fly in the ointment is that many organisations are able to cross charge departments.  So the chargeback just becomes a line item on a report where IT is able to show who is using what, even if they aren’t actually billing for it.

Private Cloud – Summary

To recap then, to build a private cloud in your data centre you need

• Orchestration Software to build your physical or virtual hardware
• Standard builds to reduce the amount of work required to automate the environment
• Define what your services are and who you’re going to offer them to.

The two biggest problems that enterprises face when trying to build a cloud is thinking it’s a technology project and trying to boil the ocean in the first go.  If you don’t bring the people and the organisation with you then your project is doomed to failure.  Automation and Orchestration is a tricky and complicated beast.  Take baby steps and learn as you go along.  That’s a tried and tested method for success

 

Good luck ;-P