Hybrid IT vs Hybrid Cloud – a changing landscape

I recently had the opportunity to speak at a CxO peer to peer networking event, run by Gartner.  I was on stage with a leading Finance Sector CTO, who described how he is deploying new systems into Azure and he’s enjoying the flexibility that brings. However he has legacy (auto corrected himself to “traditional”) workloads that due to the nature of the application will always reside within the data centre.  He also said without prompting that if you think the cloud is cheaper then you’re in for a surprise.

That story resonated with anecdotes from other customers.  The appeal of the hyperscale public cloud is it’s flexibility and speed to market.  However with most things in life, anything you rent is always going to end up being more expensive than anything you buy.  In addition, at the inception of the public cloud paradigm there were some assumptions around only running applications when you need them and therefore not paying for unused resources.  Which is fine in a research paper, a lab or a startup with only 1,000 customers.  But start adding real people (especially non-IT folk) to that mix, and overlay existing business processes into that mix – most decent sized enterprises experience is that switching things on and off isn’t realistic for a good proportion of the applications they use.

In context, I think the landscape is maturing somewhat.  There used to be a narrative that everything is agile and due to a variety of factors (security, latency, etc.) you want the public cloud agility but those factors constrain you.  So why not use OpenStack / Docker / Stackato / Vmware to have a private cloud for the best of both worlds???  Let your applications magically float between clouds. That has been the common hybrid cloud story for the past few years.

Right now I’m hearing more people talk about not everything needing to be Netflix.  Some new workloads are public cloud native and need the agility and flexibility it provides (along with associating it to a specific P&L).  But some things just don’t need that flexibility (and specifically those things are commonly running the majority of the business’ revenue driving workloads).  In addition newer workloads such as AI where the maths is so compute intensive that dedicated on-prem GPU accelerated infrastructure is the preferred platform once things get past R&D.

Today’s story is becoming less Hybrid Cloud where apps move between different environments, and more Hybrid IT where different platforms have different benefits and those are the decision points around where to host them

Where do Solution Architects fit in a new cloud native world?

Where do Solution Architects fit in a new cloud native world?

At a recent tech conference I was chatting with a colleague about his new role. Sean is a solution architect at a large tech company. But a traditional tech company, not a born in the cloud organisation. We shared some interesting viewpoints on the need for different roles in IT delivery. What exactly is a Solution Architect?

If you need some work doing on your property, you may go straight to a builder. You’re highly likely to get an architect in. Different architects will have differing skill levels and experience. But broadly they’ll have the same topics they’ve been trained on and the same certification.

In IT it’s so different. A solution architect can be an ex-developer whose role it to pull the various strands of application design together. A solution architect can be an ex-infrastructure specialist whose role it is to create a high level infrastructure design covering network, security, storage, compute, etc. Or a solution architect can be the glue logic acting almost as a technical project manager – without P&L or man management responsibility but pulling the various strands of a project together to make it a success. You can’t quite define what she does. But success wouldn’t happen without her.

Our new cloud native world has brought us lots of new toys to play with. And our fascination has gone back to twiddling knobs and playing with new technologies. Commonly if you look at a solution architect involved in AWS or Azure – a solution architect will be that technical person. Skilled in their individual platforms but much more of a tech person than a solution person. So what’s happened to our glue logic guy? Is she irrelevant today?

Back to the conversation with Sean, we discussed an engagement with one of his customers where they are developing a big data platform using SMACK to build a data munging platform. His peer is working right at the bleeding edge and is up to his neck in configuring streams, building platforms and making the platform sing. Sean took a moment to point out to the customer that their security policy means that BYOD isn’t allowed for the platform they need access to. His customer needs to get on with ordering 4 new laptops so that when the data scientists land in about 4 weeks they’ll be able to crack on.

His team mate was baffled. “Why did you bother with that? That’s their problem?”
“because if I didn’t then we’d be stuck for 4 weeks and the project would fail”

Your standard project manager wouldn’t have the integration and dependency mindset or technical experience to recognise this upcoming issue. He’d to be able to manage the issue when highlighted. But would likely be oblivious until that point. It struck us that even in the cloud native devops world where we’ve got so much new technology and new processes like Agile, the traditional solution architect role that’s non-descript but critical to pulling the solution together is still so important. Everyone likes a posh job title but it looks like we’ve promoted what we would traditionally call technical or application architects into solution architect. When really they aren’t looking at the overall solution but just really good at their smaller bit. Long live the solution architect. Best described as “useful guy to have around”

Simon and Rob discuss AWS uptime

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 2nd 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

Will containers take over the world

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.

Which Cloud do I want?

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.

 

cloudy overview

 

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.

bits of a 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.

What is a Private Cloud?

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

openstack-software-diagram

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

cloudy stuff

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

Why I bought a server instead of using the Cloud

Everything is cloud computing, Amazon AWS, etc. etc. these days.  And yet for this website I kept it old school and purchased a Linux web server I had full root access to.  Why was I such a Luddite?  A couple of reasons really.

Curiosity killed the techie

Part of this is a learning experience.  A hundred years ago I used to be a sys-admin.  I still play with Linux periodically, on laptops, raspberry pi’s and virtual machines.  But I wanted to build a thing from the ground up.  To choose my webserver (apache or lighttpd), choose my blogging software, etc.  I wanted a platform where I could do a little coding and be free to install what I wanted.  And then to secure the whole platform correctly.  In summary this website isn’t just a tool for me to share (or vent) my thoughts on a number of technology subjects.  It’s also a learning exercise

But why so old school?

One of the supposed break-through’s that Amazon AWS provides is the ability to be charged for what you use.  From a processor  / memory perspective but also from a bandwidth perspective.  Which for a small blog like this should be more cost effective.  But what happens when my massive genius delivers the post that makes me famous.  The popular web-based source code repository Github hosts their sites on Amazon’s AWS cloud platform.  When they got DDoS ‘d earlier this year (supposedly by The Great Firewall of China), through no fault of their own and completely out of their control, Github started incurring a $30,000-a-day Amazon bill.  Which is more than my little hobby can stand.

I’ve obviously picked an extreme example to make a point. But whilst paying for a dedicated virtual server is certainly not the cheapest website hosting option, it’s a known cost every month and something I can control.

The elephant in the cloud computing room

The pay per use / consumption model stands out to me as one of the major unspoken issues with cloud computing.  The implication is that we have all bought far too many servers for what we really need. If we just moved to a usage model where we just pay for what we use then that’s bound to be so much cheaper.  This concept is based on the assumption that IT (or non-IT people for that matter) have a really good idea on how specific applications are applying load to existing infrastructure.  Or they have mature processes for projecting the infrastructure requirements for future applications currently in development.

Oink Flap Oink Flap Flap

Ahem

A consumption based solution like cloud has an associated requirement that product revenue is closely tied to infrastructure utilisation, i.e. if my hosting costs increase then that’s fine because that means my product is generating more revenue in line with the increased cost.  But in reality how many people are re-architecting their applications this way.  Sometimes that’s not even possible.  Re-designing an application to tie it’s infrastructure utilisation to the revenue it will create is more than just a technology problem. It’s a business process and sales problem as well.

Summary

As a technology I’m a big fan of Infrastructure as a Service and Platform as a Service cloud technologies.  I think the problem is when we are promoting them based on business reasons and not technology reasons.  And often either the business isn’t engaged in that conversation, is just too far removed to understand the problem or even be in a position to make the required changes to adopt those benefits.

I’d share a picture of a Emperor but nobody needs to see that