What's the Cloud Really For?

 I have a problem with the word “cloud”. I do not think it means what you think it means.

 Years ago I wrote the following:

“As human beings, we have an innate tendency to address problems from within the current paradigm. It’s from time to time that disruptions emerge in such manner that we are forced to take a step back and seek a new solution starting from scratch. We are reluctant to get out of our comfort zone, but when we do, there is usually the payoff of a great leap forward.

When approaching a new challenge, the initial focus is always on getting things to work. This is the comfort zone of the  Masters of Complexity: there are our tools, there are our protocols, figure out a way to solve the problem with these tools. And in a timely and efficient manner. That’s what we engineers do, right?

When trying to build upon this, though, design decisions that made sense for the first iteration (the solution of the initial problem) don’t necessarily make sense anymore for the next iterations. At a certain point in time, there will be a need to reframe the current situation and design a new approach.”

This was written around what was hot at that time in IT, Software Defined Networking, but applies in the very same way to what’s happening with cloud in the past years.

I believe that most companies (and most IT vendors included) are still in the masters of complexity comfort zone, trying to figure out how to use our traditional tools to solve new problems. Hence expressions like “we are considering moving to the cloud” or “some of our workloads are already running in AWS”. Or, even worse, “we already have a VMware private cloud, we can spin a virtual machine in minutes”. If there was an ASCII for facepalm it would fit here. If you are thinking about “workloads”, and not “applications” or, even better, “business services”, you are not really doing cloud. Yes, you “do” cloud, okay? Don’t look at me that way. Let’s talk where private, where public and most importantly, “why” cloud.

This is all about business transformation, becoming a modern organization with continuous, fast idea iteration by small two-pizza teams that have the right tools, and are not afraid to use them. That has nothing to do with the usual strong competencies of enterprise IT teams, which are used to tickets, control, procedure. That comes later, once you have distilled and industrialized your service. But we’re way before that, we’re still hunting for the idea, and six-sigma is not the best way to find it.

Most start on step 1 of this chart and take forever to move on. Don’t if you can avoid it.

That’s why some are seeing private cloud as never really taking off. After all, it’s often built by the same people who built a career around a technology stack, and want to stay relevant. It’s full of politics, procurement-driven decisions, integrating legacy and standing ELAs into a machine that should be able to move at lightspeed and mutate constantly. IT is messy. 

Plus, running an enterprise IT shop is pretty much the opposite thing to building a cloud platform:

• At small scale, there is no sense in building a practice around DC operation. It’s way too hard to build the talent and even harder to retain it in order for it to make sense for running 500 servers.
• Enterprise IT is not suited or built to attack large distributed constantly evolving services. More like “keep the lights on, keep everything unchanged for four years until you replace it with a younger clone of itself”.
• It’s full of infrastructure snowflakes, one per custom application. You’ll never get out of there working from the infrastructure upwards, but from the code down. Standard software building blocks on abstracted hardware standardizes the platform and helps focus on differentiating efforts for your Apps, which is what pushes your business forwards, not “making the most out of those old Fujitsu servers we bought back in 2007”. You will get distracted from your main focus.
• Resiliency is haaaaard to master.
• Security is even harder, and it depends much more on how the application is architected and how you operate it, than on the barriers and controls you set up at the infrastructure level. It’s better to develop a new skillset around building applications a safer, more secure way, than trying to stem the tide.

Is private cloud then something to abandon? Is it crazy to have one? Not at all. It’s just not what you think it is.

First of all, “private cloud” does not mean “custom-made VM vending machine tailored to the software I already bought, the tools I know how to use to configure my servers, and a pretty self-service portal on top that ties to the same old ticket-based process”. Private means always-on, utility-like, on-prem, highly available, auto-upgraded, standard and open platform for any kind of app. Any other way = yak-shaving = recipe for disaster.

Of course, if you ask your IT head honcho “which kind of cloud do we need” you may get the “custom-made frankenstructure we know how to build” answer. Never ask a barber if you need a haircut.

Look instead at your app portfolio. Group them by “apps to keep the lights on” and “apps to push my business forward”. And make an educated decision around where to best deploy each component of each app. Look at dependencies, policy, scaling needs, state, performance and cost. Then make a choice around whether that component can benefit from an in-house snowflake or if it’s better served by utility computing.

For some of those it will make sense to stay private:

• Old stateful monoliths.
• Compliance and governance reasons.
• Data gravity: some data is core to your business, and there’s tremendous value in how services and users access that data. Don’t give that information away: keep it close to the chest, it’s often one of the best assets a company can ask for if it knows how to exploit that value.
• Data volume: cheap to store, expensive to access in public cloud.
• Data lock in: you will probably never get some data out of a DynamoDB database in Amazon, the same way you will probably never migrate the data living in that Oracle RAC monster you created. And boy do Amazon and Oracle know that.
• Capex amortization: some servers you already own, some storage needs to be written off the books…

Technology has been helping in making on-prem IT more flexible and capable of handling those use cases (see object storage infra and software, hyperconvergence or hybrid-cloud networking). Still, you’re probably in for a lot of Mecannoing (if that’s even a word).

Everything else belongs in a cloud you don’t build yourself. When you get distractions out of the way you can start focusing on building the skill set and the practice needed for that new way of working that’ll push your business further. The state of infrastructure conditions your organizational culture. Remember Conway’s Law. It’s vital to move away from IT competency structured teams and reorganize into small, business service oriented cross-disciplinary SWAT teams with the mission to build, evolve and run each component. That’s usually a hard transition, and there are tools and frameworks out there to help push in that direction.

Whether it is an IaaS platform you’re after or a PaaS environment based on the more modern container-based approach, there are ways to enjoy the benefit of utility consumption, a 99.99% uptime SLA and forget about HA, live migrations, rolling upgrades etc. That’s the ideal private cloud, an in-house open version of the public cloud. 

Your teams would focus on how to better use that cloud, how to learn to be masters of agility and forget how to master complexity. That’s exactly what Cisco Metacloud (FKA Metapod) offers: always on, on-prem, managed OpenStack for everyone. 

On your servers, behind your firewall, ready to use. Just IaaS or (future) with a managed PaaS environment of your choice on top (read: Openshift, Pivotal CF, Apprenda or plain Kubernetes aaS etc.). It’s a killer value proposition from the same guys that created OpenStack back in the Nebula days at NASA, Ticketmaster and others. Gain the benefit of cloud-native operations and methodology but keep your data at home, leverage previous investments and keep your CISO happy.

Still, there’s that need for modeling your application. Understanding how components communicate to reflect that in an agnostic policy that can be instantiated anywhere. Each service with its scaling properties, it’s bootstrapping instructions, firewall rules, dependencies… And benchmarking each one to know where it will perform best, where it will cost less to run. Tetration Analytics is like a time machine for your cloud, and it can show you how your services speak to each other to enhance that modeling process, and CloudCenter takes care of the rest. Check it out: it’s really something.

 And then you’re set with an open, truly useful private cloud, and a toolkit to start working towards a new paradigm. Component based development. Microservices architecture. Far greater levels of code reutilization. SOA done right this time. A utility platform that abstracts all the innards and the whole underlying process from the developer (to creates services and in the darkness bind them).

This is where public cloud really shines: most problems have already been solved, first with a custom-made, experimental solution. Then with a refined product. Now there are utility services for the majority of the needs that a business app may have: balancing, caching, databases of all sizes and flavors, message queues, monitoring, analytics… And for anything else there is compute and storage as a service for you to build your special sauce.

But it gets better: serverless (we need a better word) or “functions as a service” are what it all boils down to. As a colleague just said:

…all of this was headed toward FaaS since the times of 80col FORTRAN cards - you assembled programs by  borrowing subroutines from that other professor that had done that work before. 

Only now it’s cloudy, it’s on demand, it scales automagically and it’s subject to be monitored and analyzed.

Instead of me trying to butcher why serverless rocks, I’ll let Simon Wardley do the explanation:

I didn’t have to worry about building a platform and the concept of a server, capacity planning and all that “yak shaving” was far from my mind. The efficiency, speed of agility and speed of development are just a given. However, these changes are not really the exciting parts. The killer, the gotcha is the billing by the function. 

Billing by function fundamentally changes how you do monitoring. When I provided a service to the world, users of my program could follow very different paths through it. These we call flows.

Depending upon their flow in our system then some functions can be called more frequently. Billing by the function not only enables me to see what is being used but also to quickly identify costly areas of my program. I would often find that one function was causing the majority of the cost because of the way I had coded it. My way of retrieving trades in my program was literally killing me with cost. I could see it,  I could quickly direct investment into improving that one costly function and reduce the overall cost. Monitoring by cost of function changes the way we work - well, it changed me and I’m pretty sure this will impact all of you. 

And it gets even better. Then Wardley introduces the concept of worth-based development, or FinDev as he calls it, and suddenly there is a thousand people at the AWS Reinvent ‘16 serverless session in Las Vegas. Cockcroft thought 2017 would be the year of serverless, it may as well be. All these practices are possible because the underlying platform has been industrialized and refined until it’s become a utility. You don’t need to build that again; it’s been done for you.

FinDev is possible when you stop worrying about building a piece of software you charge for, and start billing by consumption of that software in the cloud as its end-user makes use of it. If you’re a software shop you have the incentive of making a great app for your customer because your costs are variable: you pay for whatever functions are executed in the public cloud of choice (say Google App Engine or AWS Lambda), but each execution should have a business driver behind. Your incentive is to maximize usage (customer engagement) and minimize cost (make your App efficient). No yak-shaving, no infrastructure operation, no politics: just plain better, laser focused applications. You can monitor what lines of code make you the most money, what lines of code are the least efficient. More Wardley (the man’s a genius):

This is  like manna from heaven for someone trying to build a business. Certainly I have the investment in developing the code but with application being a variable operational cost then I can make a money printing machine which grows with users. It also  changes my focus on investment - do I want to invest in increasing marketing for more users, or the conversion rate, or maybe the testing application is so badly written (or a function within it) that investing in coding improvement will bring me better returns?  Suddenly, the whole way I build a business and invest is changed. 

The co-evolution of practice around platform from componentisation to code sharing to financial monitoring to increases in agility and efficiency is a pretty big deal as we enter this serverless world. But the new business models around worth based development and the collision of finance and development will literally knock your socks off. Which is why the moniker “FinDev”.  Beyond the initial investment in coding, I can create an almost  variable  cost business model and redirect investment to maximise returns in ways that most of you have never experienced. I know, I’ve been there.

These emerging practices will spread despite the inertia. The path of adoption will be a punctuated equilibrium as with all points of industrialisation. This means the  growth is exponential and you won’t barely notice it until it gets to a few percent of the market and then in the next few years it will take over. On average the timescale for this process is 10-15 years, so expect to see the whole world being overtaken by serverless by 2025. These “FinDev” architectural practices will rapidly become good and then best but what their exact form will be, we don’t know yet. We’re not near the stage of reaching consensus and they still have to evolve and refine.

Some players are doing this on-prem too. OpenWhisk is IBM’s serverless platform, and it can run on-prem. Iron.io is also doing this and it can run on top of a regular Docker environment so it can be accommodated to most modern private cloud efforts. Again, if you can get this as a service it’s better, no matter whether it’s at home or in the public cloud. Don’t distract your teams with yet another infrastructure / platform stack to maintain and operate, focus on your business problems. You surely have some anyway.

Public and private clouds should be two flavors of the same thing: tools to accelerate your cultural transition to a different, better way of building your business applications. Any other use will be inefficient, distracting and in the long term expensive and useless. Culture is the cornerstone for this transformation that we’re after. If you’ve heard of the pioneer-settler-town planner structure, this is great advice:

Your pioneers should be all over the new practices around utility platform. They should be building apps around this space, working out how to combine finance and development into new models, how to build service repositories etc. Experiments in this space should be going wild. 

Your settlers along with helping the town planners take over any existing efforts from IaaS to PaaS, now need to be starting to hunt through all novel and emerging practices both internally and externally that will be developing around utility platform efforts. They need to be looking for re-occurring patterns and what might have some legs and be useful. They need to be looking for those spaces with potential, finding the MVP for your new line of products. Miss this boat and you’ll be kicking yourself come 2025.

Don’t build a custom private cloud nobody will use. Don’t just move virtual machines to the public cloud to use them the same way. It’s better to go full hyperconvergence and simplify to the bare minimum your legacy infrastructure and continue your legacy practices than to pretend you’re playing cloud when you’re really doing fancy legacy IT. A monolith inside a Docker container on AWS is an aberration, not a microservice :)

Instead change your roadmap and how you see the cloud.

1. Start with “why”, identify, catalog and analyze your apps.
2. Figure out where you need to go with your business services.
3. Get as a service as much as you can (either private or public where it makes sense).
4. Invest in tools that help you make the most out of that hybrid platform and that accelerate your cultural shift.
5. Then set out your pioneers to experiment and try new stuff as fast as they can in that platform.
6. Then get your settlers to turn useful experiments into valuable services for your business.
7. And then get your town-planners to industrialize those, optimize them and turn them into a utility for your pioneers to build atop and discover new stuff. 

That’s what the cloud, whatever cloud, the real cloud, is really for.

Note: Credit to Simon Wardley ("Why the fuss about serverless?") and Subbu Allamaraju ("Don't build private clouds") for ideas and images used along this post.