Software and the cloud have a language problem. Both have been around for decades and are evolving rapidly. Keeping components similar, consistent, and close to each other was mainly sensible when discussing software. The introduction of the internet and the cloud started to drive the mass adoption of distributed systems instead.
When Sam Newman published his book Building Microservices: Designing Fine-Grained Systems in 2015, the concept of mass adoption took hold. Approaches before that, like component-based development and service-oriented architecture, had similar promises and paved the way for a microservice future. In other words, it’s a little like the iPod. MP3 players and digital music advances happened for years, but Apple put the time and effort into putting the correct language, design, and innovation into the iPod. Marketing and product engineering are needed to change a market.
What does the term Modern Cloud mean?
Many organizations are moving their legacy nondistributed systems to the cloud with cloud migration. These migrations look like cloud applications, but they’re still built on legacy technology, causing the organization to lose out on the promised cost savings and increased delivery velocity.
The term modern cloud applies to applications and systems that embrace modern practices built for the cloud. Containers, managed services, event-driven programming, microservices, and serverless fall under the Modern Cloud umbrella. Of course, you can still drop a monolithic, legacy application into a container—but it’s not modern until you break it up.
Modern cloud is hard to explain, but let’s outline some characteristics. After all, understanding the details and benefits of the modern cloud is critical to the third phase of the Value Flywheel Effect if your organization is to avoid following trends and instead find your actual ‘next best action.’
Aspects of Applications Built in the Modern Cloud
- Microservices: Break applications into components deployed separately containing the data they need and speak to other microservices via service calls.
- Loosely coupled and scalable: Ideally built on an event-driven architecture, but lack of a hard dependency means applications can scale as they need to (automated).
- Cloud-native: Software is ephemeral, infrastructure as code, and resilient.
- Abstracted: Software is abstracted from the OS via containers or serverless architecture.
- Pay per use: Only pay for what you need.
- Low operational overhead: Fully (or almost fully) automate operations. There’s no longer a need to log into a computer and manually configure or install something.
- Leverage the provider: Use the cloud provider’s services to minimize overhead.
Modern Cloud Inertia Points
It’s essential to acknowledge areas of possible inertia (blocks or bottlenecks) to migrate to the modern cloud/serverless. In the third phase of The Value Flywheel Effect, you’ll encounter specific obstacles that will slow your progress, like lack of skills, capacity, security constraints, and under-investment in technical strategy.
Inertia points are different for every organization and can disrupt progress significantly. Mapping your organization will help you identify and discuss inertia points in the room ahead of time and work around them. We’ll look at this mapping technique more in Chapter 15. But for now, let’s work through a few common examples of inertia with technology in the cloud.
Legacy Cloud
If you’ve already completed a migration to serverless (the modern cloud), you are likely in a good place. Unfortunately, the cloud is evolving fast. A standard you put in place three years ago may now be outdated. “Legacy cloud technical debt” is a genuine issue.
Because you “migrated” your system to the cloud, you’ve benefited from some cost savings, but you must put in significant work to continuously move your system forward. Legacy cloud systems require constant modernization. Be wary of the sunk cost fallacy: you may have built something fantastic that worked a few years ago, but if it no longer makes sense, let go of it and modernize; its purpose has been served. The process of ruthless simplification never ends.
The technology transformation process often starts with migration to the cloud, but migration is not the endpoint. It bears repeating. Migration is not the endpoint. Successful companies in the modern cloud begin with migration, then measurement. Once everything is in the cloud, we can measure and observe the system’s behaviors. We have telemetry; we can start transformation and modernization. Once modernization begins, it never ends, but the value unlocked through the effort should show a significant return on investment.
Lack of Business Alignment
You don’t need to take your business partners through every low-level detail about your cloud offering, but they must be part of the cloud migration process. If your IT department has put a facade up in front of the business to obscure the specifics of their work, you’ll need to deconstruct it. You must have a single-team mentality to get the most out of your modern cloud. When you have your principles in place, you must move your systems forward with your business partners, not for them.
But the pendulum can swing too far in either direction. Migrate with too little buy-in, and you’ll find it hard to explain the benefits. You’ll pressure your engineers if you over-hype the migration and fail to release the promised benefits. Instead, create a one-team mentality between the business and technology and keep a next-best-thing mindset to align your stakeholders.
Fear of Vendor Lock-In
Vendor lock-in is a genuine concern for many organizations today. Some industries have regulators that may require a plan to move your workload just in case you need to. Risk mitigation is sensible, but you will spend your time better creating a system with clear boundaries and the ability to move, not creating a cloud-agnostic solution.
With other utilities (power, telephone, even banking), it took many decades to provide a fast-switching mechanism. These companies needed to improve efficiencies and standardize or industrialize—only then could they build fast switching.
The cloud industry is still evolving, so it’s premature to introduce extra complexity into your systems. It’s easier to migrate a well-designed serverless system than a poorly designed traditional system. Use your capacity to strengthen API and service boundaries. Don’t waste your time making everything agnostic. Ask any company that goes out of business with an agnostic cloud solution—was the extra spend worth it?
Serverless Is Not the Point!
It may seem like this post is being a tad overly prescriptive, but we don’t intend for it to be. The last thing we are looking to do is mandate serverless. We don’t care if your organization chooses to go serverless or not. We want you to take away from this section that in today’s environment, the ‘next best action’ for achieving faster value for your organization isn’t necessarily to build everything yourself.
Remember to underestimate the mindset change required to embrace the modern cloud truly. Some engineers will have to give up some very familiar habits. (Maybe you can’t test locally. No more manual configuration. No more blaming the Ops team!)
We’ve always believed that as software engineers, our job is not to write code but to help the business. Ben Kehoe, the lead researcher at iRobot, once said, “The point is not functions, managed services, operations, cost, code, or technology. The point is focus—that is the way of serverless.”
Again, this bears repeating, so let’s break that down:
- Functions are not the point.
- Managed services are not the point.
- NoOps is not the point.
- Cost is not the point.
- Code is not the point.
- Technology is not the point.
- Events are not the point.
- Architecture is not the point.
- Mapping is not the point.
- Data is not the point.
- Innovation is not the point.
- Even sustainability is not the point!
Serverless is a consequence of focusing on business value and offloading everything else (infrastructure and operations, for example). Serverless-first should remind you to “not sweat the small stuff”—focus on your business and delivering value to your customers instead.
It’s a Mindset for Engineers
Serverless is a mindset.
It’s a realization that you will not rely on separate internal teams to compute, database, or operations for you—the Dev team will handle it all.
You have access to everything and will ensure it all works for the business.
It’s also a realization that you will not log tickets and wait for stuff. You will move quickly. You won’t accept a three-day service-level agreement.
The power of the cloud is at your fingertips. You have the skills, and you have the business problem. Do not tolerate any slowdown. We’ve described this as a way for the enterprise to scale DevOps.
DevOps was a tremendous promise, but it relied on a significant specialty. The perfect manifestation of DevOps is serverless. NoOps is a fallacy. You must always run your systems, but utilizing the modern cloud will significantly reduce that burden. The serverless-first strategy says that any other implementation option is less optimal. If you need to fall back, you must have a good reason—and that’s okay.