How To Choose Between Microservices and Serverless Architectures

Fabio Gasparri, Hexacta, https://www.hexacta.com/

Agile software development and continuous delivery are changing the view of organizations on their software architecture and its evolution. Two current architecture trends, Microservices and Serverless, try to answer these challenges. This article aims to answer the questions you might have about their benefits and disadvantages and to help you to make the right choice for your software architecture future.

The call for new architectures in the digital era

Today's business environment has become acutely competitive. The pressure to innovate continually and deploy fast changes is intense and critical. The push to become agile is a complex transformation that takes place on many levels, from the human to the digital. But the fundamental disruption that CIOs and other IT leaders are facing today is how they will future-proof their enterprise applications.

Meeting this challenge means drilling down deep into the very foundations of their digital estates. From retail to health care and beyond, CIOs and other leaders are compelled to reexamine how their IT systems support the modern-day apps their companies require conducting business. These are the applications, the software, and the mobile apps that serve the essential business goals of engaging users, improving the customer experience, and forging a way to the future.

As a result, the development world now finds itself in the early stages of a dramatic shift. In response to the urgent call for continuous innovation and in the face of widespread disruption, software developers and IT leaders alike are increasingly using different software system architectures to build and deploy the apps of the 21st century. This article examines the new architectures that are on the rise today: Microservices and Serverless.

Moving away from monolith: New architecture solutions support organization-wide transformation

A CIO's path to transformation is never complete. Future-proofing enterprise applications requires nothing short of a grand architecture transformation in and of itself. Those burdened by outdated architectures and legacy applications are finding that eventually, those hurdles will act as barriers to their organization's ability to work toward their strategic initiatives. The goal of outpacing their competitors with continuous innovation will become a distant pipe dream.

Whether they choose Microservices or Serverless, the updated architecture solutions will support innovation by:

• Expediting time to market

• Providing long-term value as the organization is able to continually implement fast changes and keep pace with innovation to stay competitive and grow

So as business leaders launch their over-arching, top-level enterprise transformation initiatives, they must also become aware of the system changes that support those goals. 21st-century architecture solutions like Microservices and Serverless are the very structural foundations upon which a CEO's agile-driven goals are built.

The problems with the old regime: simple systems for simple times

Enterprise applications that are allowed to calcify under previous-generation, monolith strategies will not be able to keep up with their nimbler competitors. Microservices and Serverless architectures, which offer more flexibility and easier scalability, are replacing the old regime.

Monolith applications represent the traditional way of building enterprise applications. They are simple, straightforward, and for years have successfully supported business needs. However, with today's critical need to constantly improve the customer experience, business apps (both client-facing and internal) need to be continually changing shape in order to serve those user-centered goals. New features frequently need to be added and old ones need to be retired as business needs evolve.

CIOs, their development teams, and their software partners are finding monolith structures are unable to support fast-paced change cycles that today's business environment demands.

A large and simple architecture will not support a culture of constant innovation and change

As a primer for leaders who are looking to restructure or replace their aging legacy systems, it is helpful to understand the shortcomings of a monolith architecture.

A typical legacy application consists of three parts, the third of which represents a monolith architecture:

• The client side User Interface (i.e. the browser)

• A database management system

• A server-side application that covers data transfer from the database to the UI, HTTP requests, and which updates the database

If system changes are required, such as adding new interactive capabilities to the company website for improved customer engagement, the whole server side application must be rebuilt. Just a decade ago, monolith systems presented no obstacles to changes like this. Today, it is a different story. With the move to the cloud and the call for rapid responses to an ever-changing market, there is no time to update the entire server side every time there is a change.

What was once an advantage - simplicity - is now an obstacle. Under a monolith architecture, a limited number of problems could then be solved with relative simplicity. Problems could typically be solved using solutions from a limited body of resources, too. Looking back, it was simple operations for simple times.

But a single, logical executable will no longer suffice. A single process for running all the logic that is required to handle the enormous numbers of requests today's apps create just is not sustainable. In order for small changes to be rolled out continually without affecting the entire server side app, a different approach is required.

That leaves IT leaders with a few choices to make. Switching or migrating your architecture to a better system that can keep up in a culture of constant innovation and change will bring a number of benefits. Understanding those benefits is the first step.

Microservices vs. Serverless architecture

Leaders who are not yet convinced of the value of these new technological advances can benefit from a deeper dive into how and why Microservices and Serverless can help their organizations. In short, becoming an agile enterprise with the ability to scale rapidly requires IT leaders to lead the way with future-ready, adaptive solutions like Serverless and Microservices architectures. Here is a first look at how these two technologies can help you take your organization to the next level.

The modular solution: Microservices

It might be easier to understand a Microservices setup by first explaining how it solves the all-too-familiar problems that IT leaders face with their legacy systems.

What problems are solved by Microservices?

Remember: monolithic apps handle requests with a single process - a process that must single-handedly contain all functionality. In other words, make one mistake or experience even a short delay in deployment of that one feature change you had in mind and the entire application is out of service. As an organization moves its processes to the cloud, the path to scalability is increasingly fraught with architecture failures like this.

Microservices solves this dilemma by allowing developers to work on nodular components of a system while the main functionalities carry on supporting users and business goals. Modularity in this sense is the same as modularity in any other environment: comprising separate units that are replaceable and upgradable, independent of the main system. We call these units "components" and the act of transitioning or building from scratch a system of components, we call "componentization".

The importance of componentization is explained below.

The advantages of Microservices

Microservices is a rather new technical term. As influencers converge upon a workable definition, we can suffice it to say that it means a decoupling of software components resulting in a number of agile-minded improvements. Here is what Microservices can offer:

1. Create cross-team responsibility

Each component in a Microservices architecture serves a different business need. You might have a search function, a payments' area, and a product catalog within your application. Each component has its own team of developers who are responsible for everything. That team's capabilities run the entire gamut of skills and experience and together they develop, monitor, troubleshoot, and update their component throughout the entire life-cycle of the product. They handle not just UX but also other technical maintenance tasks like connections to the component's database, project management, and more.

The result is not just faster changes and fixes but also true "ownership" throughout the life of the product by the same team that created it in the first place.

2. Move faster

In every sense of the word, Microservices are about "componentization". Or, to put it in laymen's terms, why paint the whole house when just your kitchen needs a fresh coat.

For fast, effective changes in a fast-moving world, it is better to chip away at portions of change (Microservices) rather than tear everything down and build it back up again, which is what developers face with monolith structures.

3. Open up new options with decentralized governance of the application in question

The freedom to use different programming languages opens up the range of options developers have when solving problems. Some solutions are better suited to a C++ code base while for others, Node.js delivers the cleanest solution. Databases can be selected according to the components they serve rather than being restricted by the language of a monolithic system. More options lead to better solutions. Meanwhile, centralized governance typically limits developers to single technology platforms.

Decentralized governance has other benefits, too. Monolithic architectures typically have a defined set of standards that dictate the way code should be written and deployed. Microservices developers prefer to share and borrow code developed by other developers who have already faced the same problems. Battle-tested code saves time and money because it allows developers to share solutions to infrastructure automation, data storage, and inter-process communication.

Breaking down monolithic legacy applications into Microservices that can be developed, deployed, and managed by smaller teams in shorter periods of time creates shared responsibility for the code. That is an advantage making it possible for multiple teams working across different spans of time to work with the same modules, which by nature become more resilient as a result.

4. Maximize efficiency with data storage solutions that are decentralized

This is in direct contrast with older systems which funnel all data storage decisions through one central database. Dispersing the responsibility for data handling across multiple application databases reduces (or entirely removes) the need to update multiple resources every time a single app update is deployed.

5. Optimize resources with smart endpoints and dumb pipes instead of the other way around

In older approaches to development, when different processes within an application needed to "talk" to one another in order to perform a required action, developers had to pour significant resources into the pipelines of communication among those processes. The result was "smart pipelines". Processes (endpoints) were "dumb" because they lacked those communication facilities and required the capabilities of the "smart" pipelines.

With Microservices, on the other hand, developers can create smarter processes (smart endpoints), easing the burden from the connecting pipelines of communication. These smart endpoints have higher levels of capability coded into them. With their improved capabilities, they act more independently of one another, resulting in less need for them to communicate.

With the ability to get by with "dumb pipes", developers no longer have to spend time building capability into those pipes for complexities like message routing, transformation, choreography, and for applying business rules.

6. Speed up operations with automated tests and automated deployment

Automation of certain elements of the infrastructure allow for a much-needed simplification of operational complexity.

Teams can leverage techniques like continuous delivery and continuous integration to shorten and simplify the build pipeline.

Infrastructure automation is also useful at the management level of Microservices. Deployment is simple when nothing goes wrong, making it difficult to see the advantages of Microservices over a monolith system. However, it is an entirely different story when the operational landscape is marred by complexities. That is when Microservices really shine, as managers can quickly resolve issues that are compartmentalized and therefore less relevant to other modules within the system.

Remember: today's impatient and finicky users have many choices in where they do business, find information, or seek entertainment. Any slip in their user experience, as momentary as it might be, can have negative consequences that could eventually affect business metrics in a significant way.

Software developers rely heavily on monitoring and testing in order to continually be checking to see how such failures are affecting the UX. Service failures and data center failures can be monitored by automated testing during production. Ideally, problems can be fixed automatically, too.

7. Reduced development time

Deployment time is shortened because modules are created independently of one another, by separate teams. In this way, it is possible for multiple teams to work at the same time, resulting in faster deployment. Also, they code they write is more likely to be reusable as they share across teams.

8. Improve ROI by eliminating expensive hardware

Microservices erased the need to operate on expensive hardware because modules run independently of each other. As they have been decoupled, each can run more cost-efficiently on a smaller machine.

The disadvantages of Microservices

Microservices are generally a smart solution for evolving systems that need to support 21st-century requirements of user engagement through rich experiences and fast, reliable service. There are, however, just a few disadvantages of using the Microservices architecture.

1. Not every organization can handle Microservices

Most of the downsides or Microservices only become relevant when you are building from scratch. That is because a certain level of expertise is required. It is why teams who are building new systems or designing new apps are often advised to  start with monolith and then transition to Microservices once monolith can no longer support the needs of the system.

2. Monitoring is more important than ever

In Microservices, where each component might use different code and APIs, monitoring and responding to failure is a much more complex task. In any system, no matter what architecture it is based on, services can fail at any moment. It is essential that these failures are constantly monitored, so they can be fixed immediately. And with today's customer-focused culture, any glitch or downtime can result in losses that directly affect the bottom line. Users will not stand for the types of back-end failures that reduce the quality of their User Experience (UX).

3. It involves organizational change

We stated earlier that businesses are having to refocus their web and mobile strategies in order to meet the demands of today's users. Part of this entails restructuring their architecture. Another aspect of change is required in order for Microservices to take root and start providing value: leaders must also find a way to create a DevOps culture in order to supper a Microservices framework. Remember advantage number one above: cross-functional responsibility, which creates a more resilient product. But shared responsibility only works if it is backed by a DevOps culture. That can be hard to instill if an organization is large, established, or resistant to change.

4. Testing is more involved

Earlier, we mentioned that while a monolithic architecture presents number of problems (i.e. it does not scale easily), it does have one advantage: simplicity of design. That carries over to how testing is done. In a monolithic structure, the process of identifying and responding to failure is by no means easy or necessarily fast. However, it does present a simpler framework for problem solving when compared to  testing Microservices architecture.

In a monolithic structure, there is a single pipeline and "fixing and finding the leak" in plumber's terms is far more straightforward. Likewise, in developer's terms, when the supplier to a service call is unavailable in a monolith structure, it is easier to know where to look because there is just one connection to the server, where server-side transactions take place.

5. Designing with failure in mind is required

Microservices architecture has multiple modules running in different processes. Each needs to withstand failure on its own terms, meaning each must be designed for failure. If there is a failure, the rest of the system needs to be able to keep running. That is an added level of complexity over the monolith architecture. With Microservices, there are multiple connections to design for and monitor.

Remember, each module is running its own process with its own supplier to be concerned about. Each of the multiple "micro" services supporting the application must be tested continually during development to ensure it can withstand a failure without damaging the UX.

Microservices in brief

With applications that are independently-deployable and easily scalable, fewer resources need to get tapped when the agenda calls for changes to be made. That makes scaling easier and faster and it also reduces the burden on IT teams, as changes can be contained to smaller sub-sections of the larger whole. This is the essence of Microservices. A Serverless architecture, on the other hand, takes scalability and other advantages to even higher levels.

The granular solution: Serverless architecture

For some, the transformation journey from monolith to Microservices is only half of the journey. As we have seen, organizations who leverage the flexibility and scalability of Microservices enjoy a full range of business benefits. What many do not yet know is that it is possible to enjoy that same degree of benefits once more when they adopt Serverless architecture.

Applications can now be hosted in the cloud rather than on enterprise servers or rented server space. These apps rely on third-party apps and services to manage the server-side logic that was once handled in-process. They use cloud-based databases like Firebase as well as cloud-based authentication services. This is called "Mobile Backend as a Service (BaaS)". App developers can also write their own server-side logic but it is still called Serverless because, like BaaS, it is managed by a third party.

Either way, Serverless offers organizations many clear advantages, because they no longer have to worry about the server hardware or the server processes.

What problems are solved by Serverless?

As we have seen, one problem with monolithic apps is that they handle requests with a single process - a process that must single-handedly contain all functionality. It is a single process, a funnel through which all client-side user interfaces will receive input, a funnel through which all server-side actions much pass. Adding a feature, for example, must involve the very same server-side resources that support the entire application.

What that boils down to is this: make one mistake deploying or updating even the smallest feature and the entire application is out of service.

As more organizations move their processes to the cloud, the road to scalability is increasingly fraught with architecture failures like this. Microservices solves this problem but Serverless architecture provides and even better solution for many of today's businesses. This is especially true for organizations who are well on their way into the cloud journey.

The advantages of Serverless architecture

1. Let IT focus on bigger things

If Microservices ease the pressure on bottle-necked service requests being sent server side, the Serverless approach removes the server-side application altogether. Rather, it removes responsibility for managing server burden by outsourcing that entire wing of IT altogether. Apps running in a Serverless architecture are highly dynamic and can respond to stimulation through parallel routes independent of company-held resources like servers and IT personnel. This is primarily why Serverless is more cost-efficient than monolith and, certainly, Microservices.

By having a third party manage the servers in a so-called "Serverless" environment, developers are freed up to focus their resources on business logic. In some respects, Serverless architecture requires more work from the IT team (see below). But as far as BaaS goes, IT has fewer components to handle so their workload is reduced.

2. Save money on hosting

Moving services to the cloud allows businesses to shutter data centers or at least to turn off some servers. A Serverless architecture offers even more in the way of cost savings with hosting.

3. Enjoy faster speed to market

With Serverless systems, the task of building software applications is light years faster than traditional systems. Developers are able to change the lives of millions of users without changing one line of code in infrastructure. The speed of development and deployment is beyond what even a Microservices environment can offer.

4. See additional cost savings by optimizing your app after deployment

The processing speed of an app in a Serverless environment may, through optimization, become faster over time. If you are using AWS Lambda or other similar services that offer this feature, the computing costs will be reduced. If at first it takes a half second to process and you optimize it to 100 MS, compute costs will be reduced by 80 percent.

5. Grow faster and easier with automatic scalability

As your user base grows, Serverless vendors will make sure your apps grow with it. A Serverless structured app is designed to handle even a huge spike in the number of requests - as well as a sudden drop.

The disadvantages of Serverless

1. Ops Support may be elusive

Serverless systems certainly saves managers from having to worry about server administration. But the scope of operations covers a lot more than just sysadmin. Like any other app architecture, Serverless also needs to be deployed and monitored. There is also the matter of security and eventually, scaling. One disadvantage of Serverless is that it is such a new concept that many of these operations are more difficult. Currently, anyone who is building strategies to deal with these operations issues is probably going to find that there are not a lot of resources out there for support.

2. Savings on hosting is conditional

Some companies may not benefit from Serverless architecture if their traffic is consistent (there are not any spikes) and their hosting account is optimized. Organizations who are not currently using the entire capacity of their server host according to your contract might not save money on hosting when they go Serverless. It is worthwhile to do some cost-benefit analysis on this point.

3. There is more risk of malicious attacks

More cloud vendors means more surface area for attack.

4. Big apps might cost more

Long-running applications might cost more because Serverless vendors charge by the micro-second. They start the clock ticking when a piece of code "fires up" and stop the clock once the code has stopped running.

5. Infrequently-used code may degrade performance

Code that runs frequently is kept in a "ready to go" state by Serverless providers. On the other hand, code that is not run very often will be relegated to deeper storage. It may take a moment to retrieve it.

6. There is a trade-off between customization and agility

Also, since you will not have access to the server (remember, it is outsourced to a third-party vendor), you will not be able to optimize the server design to fit your unique needs. This is why all logic is located in the client.  As Martin Fowler suggests, this problem can be mitigated by adopting FaaS (Functions as a Service). This transfers some logic to the server side.

Monolith is holding you back but what is next?

Both Microservices and Serverless offer the promise of moving closer to true fault-tolerance and resiliency. Both help organizations scale. Both support what most organizations are looking to achieve. This makes it easy to know when it is time to move away from monolith but it does little to help leaders decide which is better.

This section reviews some common instances of change where one architecture may be better than the other.

When legacy has to stay, use Microservices

If the legacy system needs to stay put for the time being, then Serverless will not do. Serverless scores well in the areas of speed and cost-efficiency but those are only two factors that need to be considered. Serverless is highly granular but that granularity is precisely what makes it more or less incompatible with a large, existing code base. In other words, it is too big a jump to make when you have a legacy system. Plan for a Microservices approach, first.

When you are starting from scratch, use both

Starting from scratch offers the ability to leverage the benefits of a Serverless architecture more quickly, but not right away. If you are building an entirely new architecture, take the Microservices approach but plan to transition to Serverless.

When confidentiality is your priority, use Microservices

Serverless infrastructure can present problems when information is been shared. Cloud hosting is, essentially, shared hosting and when others are using the same vendor, it is likely that you are not the only one using their system. That is a "multi-tenant" situation in which one tenant might see another tenant's data.

Plus, with every vendor you pick up, there's an increased number of security implementations to configure and monitor (increased surface = more risk of malicious attacks).

When time-to-market is a priority, use Serverless

Startups are often a good candidate for Serverless architecture. Whether it is for venture capital (VC) funding or for quickly responding to a time-limited market or to grab market share at the beginning of a trend, Serverless offers them fast time-to-market speeds.

When you are a startup, use Serverless

Another benefit that startups appreciate is that with Serverless, they will not be paying for a server that is not being used. Without predictable usage data, they typically need apps that are highly flexible along these lines.

Conclusion

The ability of an organization to implement fast changes and to keep innovation going depends partly on whether they make the necessary changes to how IT supports their goals. But we are in the nascent stages of software architecture transformation, where only the most forward-thinking organizations have made steps towards modernization.

Companies who are successfully incorporating continuous innovation into their business practices have changed the way their enterprise software is deployed. From single process to component-based to no need to worry about servers at all (or both), each has found their unique solution.

We hope this article has helped you find your own solution. As you move forward, you will be better equipped to meet the vast competitive challenges that rise before you now and, equally important, in the years ahead.

This article was originally published on https://www.hexacta.com/2019/10/15/white-paper-microservices-vs-serverless-the-call-for-new-architectures/ is reproduced with permission from Hexacta.

---

Related software architecture articles

Chop Onions Instead of Layers in Software Architecture

A Risk-Driven Model for Agile Software Architecture

Automated Testing Strategy for a Microservices Architecture

More Software Architecture Knowledge

UMLZone.com - Unified Modeling Language (UML), Software Architecture and Data Modeling

---

Click here to view the complete list of Methods & Tools articles

This article was published in October 2019