Introduction
One of the buzziest topics that exists in computing today is over the modernization of legacy applications. With the rise of 5G, Edge Computing, and serverless architecture, many companies are wondering whether—and how—to rethink applications for today’s digital landscape. To help shed some light on these concerns, we’re introducing a series of posts that will discuss application modernization from a variety of business and technical perspectives, with a focus on one of the most widely discussed aspects of modernization, the use of microservices. Today’s post will begin with the basics by examining the differences between monolithic applications and microservices, the pros and cons of each, and how microservices cater to ongoing changes in both consumer habits and infrastructure.
Monolithic Applications
What are monolithic applications?
In general, something that is monolithic tends to be large in size, singular in its constitution, and rigidly inflexible. Monolithic applications, which are built and released as a single unit, tend to share all these characteristics.
- Opinionated design
- Tightly coupled processes
- No clear boundaries for domains or modules
- Built and deployed as a single unit
In a monolithic application, the front-end and back-end are tightly coupled and the application is built using a single software stack. All the functionality is tied to a single unit consisting of a database, client-side user interface, and a server-side application. The server-side application is a single, logical executable that reads and writes information to and from the database and delivers it to the browser, where the user views and interacts with it.
What are the challenges of monolithic architecture?
Because of their uniformity, monolithic applications are a natural starting point for smaller companies seeking to keep design, testing, and operation simple. However, as applications add features and scale, this architectural choice can result in unforeseen complexities. A bug in one part of the system can bring down the entire application, and each new bug fix or feature requires a whole new build. And because monoliths are opinionated, the options available for implementing changes are limited to the one-size-fits-all approach, preventing the use of new tools and platforms that might be more efficient for the job. In addition, applications built as a single unit must be hosted as such; as the user base grows, new resources must be provisioned for the entire application, rather than to address specific bottlenecks.
- Expensive to scale
- Lengthy deployment
- Vendor lock-in
- Inflexible
- Low fault tolerance
As such, the term “monolithic” often has negative connotations in computing, sometimes described as a “big ball of mud” with a poorly designed or haphazard structure. This negative connotation is readily apparent in some definitions, such as IBM’s, which describes a monolithic application as “an application that grew over time, became unmanageable and difficult to understand, and has low cohesion and high coupling.”
Microservices
What are microservices?
The term microservices is widely credited to Martin Fowler, who described the various characteristics of microservice applications at length in a 2014 blog post:
- Loosely coupled modules
- Divided by business capability
- Decentralized governance and databases
- Automated infrastructure
- Technologically diverse
- Communication via lightweight mechanism
In contrast to monolithic architecture, microservice applications consist of many independent components, each built to execute a single task, such as billing or shipping. Rather than the tight coupling and complex messaging that characterizes monolithic applications, microservices are loosely coupled and interact with each other via API. Each microservice has its own lifecycle, allowing each individual module to be developed, deployed, scaled, and managed independently. As a result, microservices can be technologically diverse, each using its own programming language or database solution.
A 2019 video from Google Cloud Next provides a succinct overview of the components of a microservice:
- API - provides a way of interacting with the service
- Compute resources - provides resources to run business logic
- Storage - a database, file system, in-memory cache, or other type of state
- Associated team - which develops and manages the service’s lifecycle
This last point speaks to a longstanding principle known as Conway’s Law: that the application an organization produces will mirror the structure of the organization. As such, monolithic development tends to segment into UI, server-side, and database teams. In contrast, microservice teams can be segmented by business capabilities, such as payment or shipping, making it easier to address problems with individual functions as they occur.
What challenges do microservices present?
Ultimately, the key advantage of microservices is their flexibility. From their ability to use multiple technologies to their ability to scale and deploy independently, microservices can quickly adapt to changes in technology, users, and business needs. The downside of this flexibility is that responding to these different circumstances introduces more complexity into running applications.
As a result, microservices require more monitoring and more operational management. Scaling monoliths is more expensive, but simpler, since horizontally scaling them essentially consists of creating new instances of the application over multiple servers. In contrast, independently scaled microservices require careful monitoring and management of resources to ensure they are appropriately partitioned and scaled.
Choosing the Right Design
With different challenges and benefits for both types of application architecture, why are microservices increasingly embraced by digital businesses? The answer lies in changes to user expectations and application infrastructure, both of which require a high degree of flexibility in how applications are built and run.
Accommodating new usage patterns
Monolithic applications work perfectly fine in situations that require little flexibility. However, device use is dramatically different today than it was before microservices were introduced, requiring applications to be much more agile. Back in 2013—before Fowler’s seminal article on microservices—Forrester was already rejecting the one-size-fits-all delivery used by three-tier monolithic applications as insufficient of providing the optimization, customization, performance needed to accommodate increased mobile device use. Since then, mobile device use has only grown, with Cisco’s most recent annual report noting that devices and connections growing at a rate 10x the growth of the population. As this encompasses a wide variety of devices and capabilities, screen sizes are more varied and consumption patterns—which could include anything from checking email to streaming an entire high-definition video—are increasingly hard to predict.
More recently, the 2019 App Attention Index by Cisco’s AppDynamics provides additional insight into today’s users. Among their findings were an overwhelming desire for personalized content, and issues with limited functionality, poor availability, and slow response ranking as the three most frustrating issues for users. In addition, it found that users are increasingly intolerant of poor performance and more likely than ever to delete apps or share bad experiences, making a business’s ability to assess and respond to customer needs crucial to the company’s future.
To summarize, today’s users…
- Are highly mobile
- Have diverse devices
- Want personalized experiences
- Do not tolerate poor performance
- Expect new features and experiences
Microservices provide a way to cater to modern usage with flexible scaling, continuous delivery of new features, and higher fault tolerance. In addition, they can take advantage of new infrastructure built to address the needs of today’s users.
Leveraging new infrastructure
In order to cater to changes in user behavior, new infrastructure has emerged to provide more mobility, customization, performance, and innovation. Edge Computing moves compute and storage closer to end users, which allows for lower latency and programmability at the edge—satisfying the demand for better performance and more customizable content.
In addition, 5G, the next generation of mobile networks, will allow for dramatically improved mobile performance. A primer from Qualcomm notes several of the highlights, citing millisecond-level latency and 100x the capacity for handling traffic. Hardly a thing of the future, 5G networks are already being built for consumer and private use, with Cisco reporting that 10% of mobile devices and connections worldwide will be 5G by 2023.
However, in order to fully leverage these technologies, applications will need to use a microservices architecture. To decentralize storage and computing capabilities, Edge Computing requires lightweight, resource efficient processes. In order to deliver on performance, 5G uses new architectural principles such as control and user plane separation, network slicing, and service-based architecture, which require services to be as modular, reusable, and interoperable as possible.
Emerging technology needs:
- Decoupled processes
- Reusable services
- Efficient resource use
- Interoperability
Microservices accomodate the needs of both of these emerging technologies through independent and decoupled processes that can be flexibly deployed and scaled.
Conclusion
Ultimately, microservices are uniquely suited to addressing the needs of today’s users and emerging technologies. However, since microservices introduce additional complexity, businesses must ensure that they are using tools that simplify building and running applications. Azion’s Edge Platform makes it simple to both break up monolithic applications and build new functionality at the edge. Our serverless approach means that we take care of infrastructure management, automatically applications scaling up and down as needed rather than requiring businesses to continuously monitor and adapt to resource use.
While a serverless model significantly reduces the challenges of breaking up monolithic applications, the transition to microservices still requires some consideration to ensure it is executed as smoothly as possible. The next post in this series will help businesses prepare for application modernization and develop a plan to tackle the process.
