Top 8 resources for microservices architecture of 2021

Even though we have lived through two of the most tumultuous years in modern human history, technology has marched on. This continuing evolution includes microservices architecture, which maintains its position to look at greenfield development.

In this article, I'll summarize the top 8 articles on microservices architecture that Enable Architect published in 2021. If one of these articles spurs some ideas or feedback, please consider writing an article for Enable Architect about it.

Why to use a schema registry

Using a schema registry to ensure data consistency between microservices by Bob Resleman is the first article on the list. As we create enterprise systems, moving data from one system to another is a great challenge. Bob recommends a schema registry to ensure you have a clearinghouse of supported and documented data-exchange formats. This empowers the developer to write code to validate data and check that the transformed data is correct and expected.

All too often, we do not bake systems resiliency and error reporting into the design of enterprise systems, and the schema registry provides a single point of truth about the data formats we employ. It's smart to always think about error reporting and proactive discovery of challenges with your running software.

When to use service mesh

Service mesh: why and when to use one with microservices is a great article by Deb Donston-Miller. Half of organizations surveyed reported using a service mesh in the previous year. Deb defines service mesh as a sidecar proxy sitting next to your deployed application. It is a smart router for all traffic in and out of your microservice. By removing the complexity of networking and some security concerns from your application, you can then concentrate on the business logic at hand.

Having a level of abstraction is an age-old computer science trick to make your life easier. Removing cross-cutting concerns, like networking and security, gives you a simpler problem to keep in your head, and finding a way to a more straightforward problem always helps. Deb gives you a link to review the service mesh ecosystem if you are looking for more information.

Microservices 101

Deb also wrote 5 things enterprise architects should know about microservices. Her reasons are a primer for why you should consider microservices:

1. They "hold a lot of promise" for enterprise architects by speeding up application creation and helping with production costs.
2. They "can introduce or shift complexity." She warns of microservice sprawl, which can come from poorly thought-out deployments.
3. "Microservices requires a significant cultural shift," and in a lot of ways, the technology is the easy part. Getting a large organization to make this kind of change is a challenge.
4. There are risks in converting all your existing monoliths to microservices. If things aren't broken, don't fix them, she says. Also, you can greatly improve the majestic monolith with faster continuous integration/continuous development (CI/CD) processes in your organization.
5. Microservices require new methods in the implementation of CI/CD pipelines and new technology like containers and Kubernetes.

Microservices bundled with API gateways, messaging, and serverless round out the updated technology to consider.

The fourth article on the list, Gavin Clarke's 6 overlooked facts of microservices, begins by discussing how developers generally think about microservices and the challenges people face with developing and deploying them. He challenges the definition of what "size" means in the context of deploying microservices and speaks about bloat when you have a fabric or grid of distributed services. When you have distributed services, you need to think about the bounded context of the surface area and blast radius of the interfaces between services. Ensuring you don't have near-infinite interactions is important for keeping your sanity.

His discussion of autonomy stems from Unix and Linux, which have well-known, tested, documented, and (most importantly) isolated capabilities. Having your microservices do one thing well reins in feature bloat. It also allows you to string together different services for new and unimagined capabilities. Having loosely coupled systems is a goal for making your microservices independently deployable, in which you remove the dependencies of your services on each other (as much as possible). He finishes up with a reminder that "REST is not the only way," and that you might want to consider other communication standards.

Forecasting

My good friend and long-time confidant Eric D. Schabell wrote Looking ahead: a year of container, microservices, and serverless. Our conversations are always enlightening, and Eric's writing always brings me something new to think about or helps me rethink topics I haven't reviewed in a while. Eric defines hybrid cloud and how this is consequential when you have a cloud-native approach. He also talks about the Open Container Initiative (OCI) and the benefits from the standard's portability. He then explores the requirements of microservices in modern applications and how serverless and "Functions as a Service" are poised to be the next interaction in how we create and deploy microservices.

Design tips

I published a two-part series on 5 design tips for microservices developers: Improving the user experience and 5 more design tips for microservices developers. These articles are based on my Red Hat Summit talk 10 design tips for microservices developers. The 10 things you should consider when creating microservices include making sure your users are successful at getting started and what to do as they become power users of your system.

Security and scalability are front and center in how you create and run your services. Other tips are to be consistent in how your services are documented and how you expect users to work with different but related microservices in your deployed stack. Finally, use real data and insights, not just assumptions about how people use your system. Make sure to gather data from them after they use your system for a while to get insights you couldn't get from newer users.

Setting boundaries

Bob Reselman rounds out the top 8 with The benefits of clear context boundaries in microservice architecture design. This article continues his thoughts from the first article on this list. He expands his thinking around the need to simplify the words and definitions you use in your organization. As I mention in my "10 design tips" articles, he says having consistency across your organization is essential. He uses an example about the challenges of choosing zip_code vs. postal_code in your codebase.

Bob recommends using the "don't repeat yourself" (DRY) principle, such that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system." He also says that high-quality error messages help users use systems correctly. He provides an example: "Error: 422 Unprocessable Entity -- postal_code not supported. Do you mean zip_code?"

Conclusion

Summarizing the top microservices articles from Enable Architect in 2021 takes me down memory lane. The consistent themes over the past year—reining in complexity, making systems as simple as possible, doing things consistently, leveraging standards, and modernizing our systems—are timeless.

We will have more than enough work to do for the foreseeable future as we rearchitect our old systems and establish guidelines for creating our new systems using the powers of microservices development.

Have an enterprise architecture topic that you're passionate about? Consider sharing your knowledge by writing about it! Consult our contributors page for more information about becoming part of our community.