The ability to deliver software is no longer a differentiator. In fact, it is a basic requirement for survival. Companies that embrace cloud native patterns of software delivery will survive; companies that don’t will not.
In this webinar, we will:
- Look at the common patterns that distinguish cloud native companies and the architectures that they employ.
- Discover that an opinionated platform, one that stretches from the infrastructure all the way to the application framework, rather than ad-hoc automation, is an essential component to an enterprise's cloud native journey.
- Show that the combination of Pivotal Cloud Foundry and Spring is the complete cloud native platform.
Well good morning. Welcome to the Cloud Native Journey. I’m Matt Stine, and among other things I run product management for Spring Cloud on Cloud Foundry at Pivotal.
Which incidentally I wrote a little book on, and we’re going to sign and give those away here in the Hang Space at 10 o’clock.
We started this journey a few years ago, when Marc Andreessen made the movement defining statement that “Software is Eating the World.” Well, that was a few years ago. It has now become absolutely clear that software has in fact eaten the world.
Gartner recently announced some very telling observations, including that 45% of surveyed IT organizations have prioritized app modernization, and predicting that by 2020, 75 percent of application purchases supporting digital business will be "build," not "buy."
What does this tell us but that the ability to deliver software is no longer a differentiator.
In fact, it is a basic requirement for survival. Companies that embrace cloud-native patterns of software delivery will survive; companies that don’t will not. The battle will be fought amongst the cloud-native companies, and their differentiators will be in the digital experiences they are able to create for their users.
So, if that’s true, what is it that the cloud natives do?
Well, in my quest to understand these companies and how they operate, I’ve identified four key patterns. Speed, safety, scale, and what I’m now calling “ubiquity.” I used to call this mobile, but what I’m really trying to highlight is the idea that anybody, anywhere, can at anytime interact with your services. Speed is obvious - we can innovate, experiment, deliver value quickly. Safety balances speed with the simultaneous ability to maintain stability, availability, and durability. And scale refers to our ability to elastically respond to changes in demand.
The cloud natives practice continuous delivery. Well what does that mean? It may help to invert the phrase.
Delivery Continuous. Or perhaps better.
Deliver Continuously. You see, it’s not enough to deploy something. That’s just Day One. You also have to deploy again, and again, and again. And when you do that, you can’t break stuff. That’s day two…and beyond.
So operational discipline is key to cloud native. If it cost you anything to run something, on some time scale the operational cost dwarfs the creation cost, and if the operation cost is high, that day comes quick. If the fixed cost of deployment is high, then you end up spending all of your money, and you can’t develop anything anymore.
So what are we continuously delivering? MICROSERVICES. What are microservices? Well here’s Adrian Cockcroft’s definition. SOA. Loosely coupled - I can deploy my service any time I want. Bounded context - I don’t know anything about surrounding services other than their API’s - not their internals.
Of course the problem with microservices is that you end up building these huge distributed systems. And if you’ve spent any time with those, you know that the probability of any part of the system failing increases exponentially with the number of nodes. So we end up with this tension between microservices enabling us to deliver faster and scale independently, but making it more likely that something will fail.
And so we have to figure out how we can build reliable systems from unreliable components.
And maybe we’ve tried this sort of thing before! Maybe you’ve tried to take some legacy apps and shove them into a container and forklift them into the cloud. It’s an incredibly hard problem to solve, mostly because of implicit, poorly understood, and complex contracts. We’ll talk more about contracts a bit later.
What should be painfully obvious is that we cannot try to build and run microservices the same way we built and ran our legacy applications. That will kill you.
So what do we do? Well, I’d like to start with what you should not do.
Cloud Native does not mean build a massive DevOps team and tell them to go configure all of the infrastructure, orchestrate all of the containers, compose the distributed systems, and generally support any kind of ad-hoc, general purpose automation you might dream up like configuring load balancers or creating NFS mounts.
I think my partner in crime Andrew Clay Shafer said it best - “ad hoc automation is a problem masquerading as a solution.”
GREAT JOB PROVISIONING SERVERS THIS YEAR!
Wait for it!
…said no CIO ever.
And I know we’re really excited about containers now, but the CIO isn’t going to congratulate you for orchestrating containers either.
OK, so maybe ad-hoc automation is not the right path. Perhaps we’ll build our own platform then. Other smart people have obviously already built these, but those are web unicorns. We’re the Enterprise.
And we need an ENTERPRISE CLOUD. We’re different from the web unicorns. We have special needs. And we know best how to translate the operational characteristics of the cloud into our world. (Nevermind that we’ve never built anything like this before.) Our cloud will let us customize everything to meet the unique needs of of our applications.
Now I’ve gone down this road twice actually. The first platform I built was domain-specific. Its job was to support building and running laboratory management systems. Everyone knew it was going to be awesome. Unfortunately it took three years before it ever saw a production app. The second was a fairly opinionated general purpose platform stitched together from “best of breed” components. It took two years before it saw a production app. So at this rate, maybe if I do it two more times I’ll get to where I want to go.
I regret to inform you, but you’re not that smart, different, or special. And I’m talking to myself here as well. When I built that first platform, I thought I had special knowledge. But in hindsight, as it turns out, my needs were not significantly different from the web companies in any way. And where they were, they weren’t going to be met by the platform anyway.
What’s cool about Pivotal is the our breadth of real world experience. You get to talk to people all of the time that built amazing things. And so I asked folks like Ben Black, who was part of the birth of AWS, and Adrian Cole, who spent time at Netflix, Square, and Twitter — “what’s the ratio of developers working on real business facing apps vs. platform?” Across the board, the answers are within some small delta of 10:1.
Ultimately, the degree to which you expend human capital on building delivery mechanisms is a prime indicator of your likelihood of failure. So we’re going to spend the rest of our time talking about an opinionated platform, which in my mind is the only way you can achieve this level of effectiveness, because it destroys the need <TRANSITION> to perform such undifferentiated heavy lifting and simultaneously provides you with the capabilities you need to continuously deliver digital experiences at scale and speed. Don't waste time figuring out structure for your platform - use all of your brain power on differentiation. Because that’s what your competition will be doing.
And during those studies and relating them back to what I’m working on, I’ve discovered this path. That if you built systems based on simple rules, with commodity components, and have explicit contracts between those components, you can build pretty complex behavior without some massive centralized brain that’s running the whole thing.
One of the first things that you look at in the Complexity Explorer’s classes is the behavior of ants. Ants are able to do pretty amazing things, from the construction of complex intricate structures in their colonies, to building bridges out of their own bodies, to building rafts from their bodies that form a Gore-Tex like structure that repels water and is incredibly difficult to sink.
Walk through the simple rules.
What’s amazing is that we have deduced these rules, modeled them in simulation, and managed to reproduce the same structures in those simulations.
So…what if our platform worked this way? Some do.
Amazon started with very simple rules. These from the era of actually provisioning physical hardware, with the agreement that said hardware would be available FIVE MINUTES after the ticket was filed. In order to do this, Amazon had anywhere from 3-5 different server builds — t-shirt sizes if you will — and you were allowed zero deviation or customization from those. And if your software didn’t fit, your software was considered broken.
Another way to say this is that “PLATFORM IS OMAKASE.” It should be a meal consisting of dishes selected by the chef.
I’m going to start at the top of the Pivotal stack and work my way through all of it’s different interesting layers, starting with Boot.
<RIFF ON BOOT>
<RIFF ON SPRING CLOUD>
About opinionated expression of distributed systems patterns. Drawing from existing implementations.
<RIFF ON SPRING CLOUD DATA FLOW>
Does the same thing for the unique management needs of batch and stream data processing workloads. Foundation for message-driven microservices. Opinionated wiring of components and message buses.
All of these Spring components of course fit together into a platform built on a foundation of battle-tested components for web, data, integration, and batch workloads, built on the mature and trusted core of the Spring Framework.
And then there is the platform runtime itself, which brings its own strong opinions from the infrastructure layer up, including how best to orchestrate IaaS clouds to deploy, update, and manage the health of the platform itself, all the way up to elastically managing the lifecycle of your applications and their backing services. Along the way, we’ve created a hand-in-glove relationship between the Spring App Framework Platform and the CF Elastic Runtime Platform.
But what about polyglot programming? Isn’t one of the promises of microservices that everyone can write their services in whatever languages they choose? Sure. But polyglot is a RED HERRING <TS>. Polyglot is not what makes you productive. Polyglot actually makes it harder to enforce the simple rules and explicit contracts that make the platform so powerful. Is it impossible? No. But there’s definitely a cost to providing the same omakase experience to every taste in programming language.
So let’s look at the four things again and find them in this platform.
12 Factor
BOSH Release
BOSH CPI
So what are our commodity components?
Wait for it…. 1000’s of MICROSERVICES
With your platform needs met, you can start to deal with the organizational challenges that you have. Conway said you can’t help but reproduce in your architecture the structure of your organization. So now you’ve freed up brainpower to think about where you are and where you need to go.
You then have the ability to invoke the “Inverse Conway Maneuver,” taking steps like Netflix did. Once you decide the architecture that your system needs to have, you can restructure your organization to look like that architecture, and according to Conway, that architecture will emerge.
And then you can get about the business of delivering the business capabilities that will differentiate you from your competitors.
<RIFF ON THIS SLIDE A BIT>
What if you don’t have a platform like this?
Read the bullets basically.
We need the platform to remind us of the facts that we discussed earlier. We’re not that smart. We’re not different. We’re not special. The platform constrains us to keep thinking about delivering software.
And so we’re able to get back to the business of delivering the thing that actually makes our customers awesome, which in turn is what empowers us to win.