Cloud maturity and the unseen debt

Posted by John Mathon on Dec 10, 2017 8:13:14 AM

We are still at an early stage of cloud deployment for the vast majority of companies in the world.  However, surveys show that this is changing rapidly.  The cloud has proven itself in cost, reliability and security.    In fact, the onus has gone the other way now.  

There are more and more companies that appear to be almost at a fever pace to move to the cloud.  I have heard arguments that Boards of Directors of companies are skeptical of companies that don't have an aggressive cloud strategy.  Thus, many IT managers, CIOs, CTOs, CEOs. are emphasizing moving to the cloud sooner.  

    "I can't remember talking to a company that wasn't building a cloud infrastructure. " 

The bigger companies in many cases have taken a typical NIH approach to cloud which means essentially building and assembling a lot of the technology themselves.  This is certainly how early companies in the cloud did it.  Companies such as Google, Netflix, Facebook built their own hardware originally from the ground up, redesigned operating systems, built many of the open source projects that pushed BigData into the limelight . 

Few companies have the desire or skill to build things from scratch and they don't have the need to do this.  For many companies the paradigms and architecture in their use cases are not much different than many other companies.  

If you are a hotel chain, your use case is very similar to other hotels and hospitality businesses as well as online ticketing services.  If you are an IOT maker there may be a few different use cases that need different levels of data storage, performance and security but we know how to build these use cases now.  We don't have to start from scratch.

Rapid Technological Change

Over the last few years massive innovation has occurred in Cloud technology.  Rapid adoption feeds rapid improvement and rapid change.  This makes it hard for most companies to keep up without expending a lot of effort to find the most knowledgeable people. 

For instance, just 1 year ago there were 3 or 4 strong players in what is known as the container scheduling tools.  These include Kubernetes, Docker Swarm, Mesos, ECS from Amazon.  We have seen in the last 12 months a lot of consolidation in this particular market to Kubernetes and ECS.  

Even Amazon and Microsoft have noticed this move to Kubernetes.  Both companies are now offering a Kubernetes alternative to their cloud offerings.  Amazon announced this last week with EKS and Microsoft several months ago.  In addition, companies such as RedHat OpenShift and CloudFoundry Pivotal have adopted Kubernetes.  

If you were a big user of Docker Swarm or Mesos last year you would be questioning how you made this choice and if you should switch away while you are still early in your cloud deployment.  The same thing happens in every area of Cloud technology.  Everything from BigData vendors and tools for performance monitoring to storage technologies, security tools, CI/CD tools for rapid deployment of fixes have undergone tremendous change and improvement.  

If you are moving to the cloud you should be aware you are operating in a rapidly changing industry.  I don't think this is a huge surprise to many.

Containers Is A Revolution To Track

The ascendance of Docker and Kubernetes reflects another huge technological change that has happened in the last couple years.  We used to deploy into the Cloud using virtual machines.  The cost benefits of deployment using virtual machines is much lower than the Docker/Kubernetes container approach.  

This is so obvious to almost every CTO and architect that Docker has grown in several years to a multi-billion dollar multi-billion downloads platform.  The Docker container movement (Microservices) is so prevalent that I hardly see anyone moving exclusively using virtual machines anymore and those that are almost always are moving legacy applications that are not worth reworking.  

While the reason why to move to using the Docker container approach in the Cloud is obvious technically and a huge cost win it is harder in some ways to manage your infrastructure as containers.  Instead of deploying a single VM for an application and replicating it as you build demand, you now have 10 containers that need to be managed, secured, deployed for every VM and replicated.

Whereas it may have been possible to manually deploy and manage VM's for your applications and services in the cloud this is not really practical with container architecture.  Further, a huge reason to move to the Cloud and to container architecture is the rapid change allowed by this technology.  

DevOps First

If you are moving to the Cloud; a big reason for doing this is cost, but for most companies the bigger reason is that you can reach your customers easier and update them more frequently.  Studies show that containers are not only 50-90% cheaper to run than VM's but companies deploy 13 times more often with a container DevOps approach than with VM's.  A company which can meet its customers needs that fast will beat companies that can't.  

This is considered by many business leaders a critical difference in the new economy and between companies that are able to be successful in today's world and those who are always behind and laggards. 

Books such as the Phoenix Project and others have been preaching this agile company culture for years and it is well accepted.  This is not just a software strategy but informs the entire business and the way companies deal with customers in today's technology.    This is sometimes called DevOps First.  I strongly believe a huge if not dominant reason to move to the Cloud is this DevOps First idea.

 Where Does Agile Stacks Fit Into This Picture?

Agile Stacks was founded by myself and Igor Mameshin based on the idea that there was a missing piece of the puzzle for most companies between the Google "Do it from scratch" and the All in one solutions offered by basically turning your IT over to a company which put your IT together frequently using their own technologies they have a stake in (Opinionated) solutions.  

Many companies go this latter route, such as Ford Motor and spend many millions of dollars on consulting shops.  However, many companies (millions of companies) cannot afford to spend the millions and millions to have a consulting shop come in and take over your Cloud IT.  

The Agile Stacks Approach

Agile Stacks is a third path.  You can go to the Agile Stacks site, pick the components you want to use in your IT infrastructure.   

To build an IT infrastructure from open source or other components involves building IT that can do the following:

1) Provide Security for whatever you build

2) Provide reliability and automatic fail over recovery

3) Performance monitoring

4) Storage systems, databases and BigData solutions

5) Scaling Services to scale containers as load builds

6) Load balancers and other network features 

7) Dashboards for usage, security, performance and reliability

8) Log collection and searching as well as alerting

9) Authentication, Authorization across the tools and infrastructure

10) Continuous Integration and Build

11) Continuous testing and deployment with CI/CD pipelines that fit your development environment

12) An Automation and Tool framework for building environments with these tools repeatedly and reliably

13) Task and container  scheduling

14) Privacy, security scanning of various types and certification for NIST, HIPAA or PCI.

The list of basic features above for a typical basic DevOps First solution consists of 30 or more open source products, each of which is a container in a microservices architecture.  

It is very easy to deploy a single container in the cloud and people can be lulled into feeling like this is  easy as they can demonstrate things running very fast.  

Your IT team shows great ability to stand up this or that.  However, do you know if your Cloud Infrastructure has the basic capabilities listed above? 

Over time key features that are essential for a working and useful IT infrastructure that will allow rapid CI/CD DevOps First so you can deploy changes rapidly becomes harder and harder as the complexity of your cloud infrastructure grows to meet the requirements listed above.  

It will typically take 5-10 DevOps engineers, security experts, operations and  full stack developers 6 months to get something up, 1 year to 2 years to get your IT infrastructure up to the maturity you need to support your customers, to have the reliability, scalability and security you need.

I've Seen This Story So Many Times  

The typical company business leader is not aware of the technical challenges in keeping up with the Cloud industry, maximizing advantage of industry knowledge or what risks they are taking with their Cloud infrastructure.  

We sent some people to the AWS Invent conference a couple weeks ago.  We came back with more than 40 lessons learned from key failures that most companies don't even know await them,  Compatibility issues of one product with another for instance. 

One that struck me was a presentation by Hubspot.  Hubspot was finding it difficult to get beyond 4 9's of reliability in their Cloud services.   After working with a product that looks at network traffic carefully they were able to pinpoint that occasionally AWS would allocate a machine to their cluster which performed poorly.  Network timeouts are killer for a Cloud service.  Netflix showed this can kill the performance and reliability of their Cloud services.  

Hubspot found a way using a third party product to detect machines which performed less well especially their networking hardware or combinations of services on the node that produced long wait times.  A huge advantage of the Cloud over in-house hardware is that rectifying this is as simple as an API call to remove the node from the cluster and allocating another node and then deploying the services on the new  node.  

Doing this they were able to jump from 4 to 5 and even 6 9's of reliability according to the conference speakers.

The point is that the maintenance and knowledge needed to keep a Cloud Infrastructure at a high state of scalability, reliability and to ensure privacy, data and other security concerns and to keep everything running smoothly is a lot harder than those first few "docker run" commands.

Automation For Repeatability, Security And Problem Resolution Is Critical

One of the key things for building a reliable and secure and fast changing IT infrastructure in the Cloud is automation.  Essentially you want to be able to deploy your entire production, dev and test environments rapidly and repeatably.  This is the Agile Stacks story.  

You may want to deploy to test new features or performance, you may want to deploy copies of your production environment in different regions or with slightly different architecture for different privacy concerns.  We anticipate that as people leverage the Agile Stacks simplicity to design stacks customers will have many stacks deployed.

When you sign into Agile Stacks you can pick among 30 or more open source components and design your reference architecture in one step.   You then add your unique components to the stack.  We call this a SuperStack because it is a complete description of your infrastructure as code.

IAC (Infrastructure as Code)

When you design your reference architecture you name it, tag it and then save it.  It becomes a permanent record of what you can deploy or have deployed and how.  You then perform operations on this entire "SuperStack" such as deploy, undeploy, clone, upgrade, promote, rollback and more.  Using the Agile Stacks Control plane all the operations are automated and completely computer generated and saved so you can reference your deployments reliably and see how it was deployed, what has happened to it, and be able to replicate it easily.  

The Agile Stacks vision includes the idea that you may have several reference architectures in different groups.  Over time your SuperStacks will evolve and Agile Stacks makes this easy.   Agile Stacks provides all the automation for the components we integrate and this list grows daily.  The automation includes everything needed to do the operations described above as well as all the integration so these components operating out of the box the instant you hit deploy (or a few minutes after).

 Agile Stacks has intelligent and best practices automation that is based on our patent pending SuperHub technology that insures that the stack you deploy will run reliably, that we are incorporating the best practices such as how to reduce costs, how to optimally deploy onto what machines, usage collection for cost analysis at a more fine grained and more useful level to figure out how to cut your costs.  Things like utilizing spot instances when possible makes it possible to cut costs 90% in some cases or using Function as a Service (Lambda) can drastically cut costs.  Agile Stacks makes evolution of technology vastly less risky, easier and less costly for you to stay on top of.

This Is An Introduction To The Agile Stacks Story

 One of the next blogs I will write is describing the "maturity model" for Cloud deployments.  This is critical for companies to understand.  They may think everything is hunky dory in the Cloud and not realize the debt or technical holes they have.  By looking at the maturity model you will be able to see that you may have gaping holes that makes some future plan much harder or expose you to risks you didn't know you had.

Stay tuned for more blogs

Agile Stacks will be announcing the company's more public presence and emergence from stealth mode in a few days.  We will be announcing partners working with us and greater availability of our product to customers.   Stay tuned.

I hope you will be a beta user of the Agile Stacks technology.   This could drastically cut your costs in the Cloud, getting to the Cloud, maintaining your presence in the Cloud and give you less risk, more reliability and faster time to market.

Topics: DevOps First, Full Stack Deployment

Subscribe Here!

Recent Posts

Posts by Tag

See all

RSS Feed