What is the Modern Cloud/Serverless? This post, adapted from The Value Flywheel Effect breaks down what exactly this new trend is.
Software and the cloud have a language problem. Both have been around for decades and are evolving rapidly. For software, it was mainly sensible to keep components similar, consistent, and close to each other. The introduction of the internet and the cloud started to drive the mass adoption of distributed systems instead.
When Sam Newman published Building Microservices: Designing Fine-Grained Systems in 2015, the concept 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. Practices such as containers, managed services, event-driven programming, microservices, and serverless all fall under this 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 are critical to the third phase of the Value Flywheel Effect if your organization is to avoid following trends and instead find your true 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 away 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 services that the cloud provider offers to minimize overhead.
Modern Cloud Inertia Points
It’s essential to acknowledge areas of possible inertia (blocks or bottlenecks) to migrating to the modern cloud/serverless. In the third phase of The Value Flywheel Effect, you’ll encounter some specific obstacles that will slow your progress, like lack of skills, lack of 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.
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 very real.
Because you “migrated” your system to the cloud, you’ve benefited from some cost savings, but you must put in a significant amount of 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, then 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 measure. 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 huge 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. If you over-hype the migration and fail to release the promised benefits, you’ll create pressure on your engineers. 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 ever need to. This is sensible risk mitigation, but your time is better spent 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 be able 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. In fact, we don’t care if your organization chooses to go serverless or not. What we want you to take away from this section is that in today’s environment, the next best action for achieving faster value for your organization isn’t necessarily to build everything yourself.
Do not underestimate the change of mindset required to truly embrace the modern cloud. 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; our job is 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 why 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 be a reminder to “not sweat the small stuff”—focus on your business and deliverying value to your customer 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 run compute, database, or operations for you—the Dev team will handle it all.
You have access to everything, and you will make sure that it all works for the business.
It’s also a realization that you are not going to be logging tickets and waiting 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 tried to describe this as a way for the enterprise to scale DevOps.
DevOps was a tremendous promise, but it relied on a significant specialty. We believe the perfect manifestation of DevOps is serverless. NoOps is a fallacy. You always need to 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.