Modernizing How You Build, Part 1—The Modern Application

As an Enterprise Strategist, I spend time with customers discussing modern practices and techniques that enterprises are adopting to create business agility. These practices and techniques are also the foundation of today’s “modern application.” However, defining the “modern application” for builders and leaders can be difficult for one very important reason: the “modern application” does not exist. It is not a thing. The modern application is, instead, all about the approach you take to building applications based on the techniques and technologies available to builders today.

Werner Vogels outlined the Amazon modernization journey and how businesses building modern applications “spend more time on the logic that defines their business, scale up systems to meet peak customer demand easily, increase agility, and deliver new features to market faster and more often.” If we look back in time, the Agile Manifesto was first published in February of 2001,[1] AWS was formed in 2006, the term DevOps was coined in 2009,[2] and when I worked at CIGNA in 2005, we were building a service-oriented architecture with supporting products from companies including IBM. Most enterprises have been building monolithic applications for many years, and these applications have created challenges when trying to adopt these practices and technologies at scale. So, why are we still building and maintaining monoliths?

Looking back, there were many good reasons for building monoliths. Given the lack of simple and connected building blocks, building new applications was hard and time consuming. The amount of work involved to assemble frameworks for your new application, provision foundational infrastructure and setup monitoring and operational procedures was significant. And, your development and operational teams were already familiar with your existing application. Therefore, it was easier to build more functionality into the monolith. So, for years we built monoliths and for years and years we have been trying to move away from them.

These large, tightly coupled applications offered buckets of functionality and were accompanied by an architecture that made it easy to continue building upon the foundation. But that growth and bolting on led to bloat, technical debt, and interdependencies that ultimately made us slow and change difficult. The waterfall software development[3] methodology fit this paradigm well, because you had to plan a lot up front to ensure all the pieces would come together in the end. Yet, it often did not work out as planned due to the large scope and amount of change involved…cue the manual processes and launch heroics!

We live in a different world today, a world enabled by cloud technologies that continue to grow and shape the world. These technologies provide the building blocks to morph how we build and subsequently how we organize our teams, what they own, and how much of an impact they have on our businesses. Which is why I, and many leaders, tend to couple Agile, DevOps, and cloud transformations together into a unified strategy.

The modern application of today, which could very well be different tomorrow, is typically built with the following approach that differentiates it from our storied past.

1. Shrink the scope.
2. Choose the right tool for the job.
3. Offload the undifferentiated pieces.
4. Connect the building blocks.
5. Automate everything.

Shrink the Scope

The microservices pattern has been around for years and is an evolution of thinking in our industry about how best to create isolated services. But don’t be fooled by the use of “micro” in the name. While the scope of the service is important, it is more about building an independently scalable and deployable unit of functionality that can be owned and operated by a single, small team. The microservices pattern is important in transformation or “modern applications.” In addition to the benefits of independent scalability and reusability, it goes well with Agile and DevOps practices. Ownership and autonomy are important characteristics of successful and productive “you build it, you run it” Agile teams.

To provide autonomy, you must reduce friction across the board. Many practices that slow us down exist to prevent people and software from inadvertently conflicting with other changes. However, these same practices force us to hold back changes, creating large change sets and the need for greater coordination. The conflict these processes look to prevent would occur in the code base, in release coordination and execution, in the operations of the production environment, and in prioritization. A great way to eliminate this conflict is to break things up: making them independent and making it possible to deliver value within that chunk in isolation.

The microservices pattern does exactly this, and it ultimately allows us to shrink the scope of changes to a manageable size. While the broader system will likely become more complex as you introduce microservices, change management and operations of each component of the system becomes easier. As we couple this pattern with Agile and DevOps practices, we increase agility and reduce the impacts of failures while making it safer to learn quickly.

Choose the Right Tool for the Job

For many reasons, including the technology available at the time, many of us used relational databases to solve every problem: we had a hammer and everything looked like a nail. That does not just apply to databases. At Dealer.com we used Tangosol Coherence (now Oracle Coherence), a fully featured distributed cache. We used it for everything: in-memory caching, write-behind caching, and even queuing. Yes, queuing. And it worked well, for a while. Today is different though, and as Werner discusses, builders now have choice.

By reducing scope and creating isolation with microservices, builders can now select the most appropriate and purpose-built solution for the problem they are facing. This allows us to optimize the solution at all levels of the system and scale that solution based on the specific needs of that smaller function. Choosing the right tool allows us to be more specific and more intentional with how we build and operate our solutions.

Offload and Connect

Since builders are now able to choose the right tool for the job, these modern applications take on new shapes and require less logic and operations to solve the problems we face. However, as you make choices, it is important to offload as much of the undifferentiated work as possible. In the past, builders spent a significant portion of their time exploring new technologies, configuring and tweaking frameworks, and learning how to operate the foundation in order to appropriately solve their problems. The resulting complex environments were challenging to operate and troubleshoot. Often times, these applications were built by cobbling together technologies from disjointed providers with varying degrees of management and operational support and tooling.

With fully-managed services and serverless offerings, modern applications can offload the operations and management of much of the middleware/foundation and leverage out-of-the-box connectivity to the other cloud services. The cloud provider takes responsibility for the critical work of improving, operating, and securing these services—the building blocks. This allows application owners to focus on business logic and connecting these services to build meaningful solutions. By choosing a service like AWS Lambda or AWS Fargate, builders no longer have to consider where their code is going to run, if they have enough capacity to handle the load, or how to create and manage a coordinated fleet. Builders are able to write their business logic, configure their compute and memory needs along with elasticity and security, and then monitor, operate, and iterate over time.

Automate Everything

AWS builds services that can easily be connected, making it easy to handle different workloads, respond to events, gain insights from streaming data, or create intelligent applications through machine learning. But another benefit is that these services offer APIs that allow you to programmatically interact with them and automate operations and deployments. Now you can build a CI/CD pipeline that includes infrastructure and security, not just the deployment and testing of your functionality. As Werner said, automated release pipelines allow Amazon to “rapidly test and release lots of code while minimizing errors.”

In addition to the automation of release pipelines, automation can offload work for teams and create consistency and speed of task execution. This provides another opportunity to focus more on business value by improving system resiliency with automated system healing or automatic threat detection. By automating every aspect of your stack, you can meaningfully increase your deployment frequency, decrease your lead time for changes, decrease your mean time to recover, and decrease your change failure rate. Research shows that improving these metrics will lead to high-performing teams and more frequent value delivery.

A modern application combines these techniques and technologies to maximize value delivery while minimizing failure and decreasing time to value. This agility is changing how businesses operate and is opening the door for new innovations. It’s an exciting time to be alive. Go build. Build modern!

If you are wondering how to take the first step, read part 2 here.

Bryan Landerman
Enterprise Strategist & Evangelist @ AWS
@bryanlanderman
brylando@amazon.com

[1] – https://agilemanifesto.org/history.html
[2] – https://theagileadmin.com/what-is-devops/
[3] – A basic definition of waterfall can be found here: https://www.lucidchart.com/blog/waterfall-project-management-methodology