The purported death of microservices has been a hot talking point this year, generating 32-point headlines and innumerable think pieces as the software development community tries to figure out what’s next. An incendiary blog post by Amazon revealed that reducing microservices in Amazon Prime allowed them to cut operating costs by a staggering 90%. This revelation started the domino effect, as more and more companies and developers joined the pile-on. Expenses are just one problem with microservices, it turns out. Adopting microservices can lead to security issues, increased lag time, and API sprawl if you’re not careful.

In the wake of microservices’ death knell (which is being sounded too hastily, it turns out, as we shall see), some developers are turning to ‘macroservices’ as a middle-ground between microservices and the monolith. To find out how, we’re going to unpack macroservices to look at how this architectural style can solve some common problems with microservices.

What Are Macroservices?

Microservices have been popular for over a decade, debuting in 2011, although the concept of “micro web services” has been in circulation since 2005. In comparison, the idea of macroservices is brand new, having only come onto the scene this year.

So, what are macroservices? Coming up with a clear definition of macroservices will help give you a clearer idea of how macroservices might solve the issues of microservices.

Grasping macroservices requires a thorough understanding of microservices and monolithic architecture. Simply put, microservices are small components meant to perform one specific function. Microservices are generally loosely coupled and meant to be reused across projects. Monolithic architecture, often called “the monolith,” is the technical name for a traditional architectural style where everything is unified. You might think of monolithic architecture as “self-contained.”

Macroservices split the difference between microservices and the monolith. Often, a macroservice is simply a monolith that has been broken down into smaller monoliths. Likewise, macroservices can perform similarly to microservices but with some key differences. Unlike microservices, macroservices often share a data store with other macroservices or applications. Macroservices often offer access to multiple data objects or processes, as well.

In a macroservice, every function is defined as a module. Individual macroservices may be made up of multiple functions, however. They tend to be tightly coupled but can be decoupled with little effort. Each module should have its own entry point, as well. Modules inside a macroservice can depend on other modules provided they can also be converted to a REST service.

How Macroservices Solve Issues With Microservices

As we saw with Amazon Video, microservices are not the best solution for every single. While microservices can be truly revolutionary when used in the right way, they can also cause bloat, increase lag, and increase overhead, production costs, and operating expenses exponentially.

Here are some ways that macroservices could help solve some common issues caused by microservices.

Design

The buzz around microservices inspired many people to jump on the bandwagon, even if there was little technical justification. Implementing a microservice with little forethought is a fantastic way for a microservice to spiral out of control.

Macroservices require forethought and planning by their very nature. Seeing as how macroservices are made up of individual functions bundled together, you need to think about shared resources, data flow, permissions, and scope as part of the design process.

Monitoring

Microservices confound a lot of traditional monitoring solutions. Conventional monitoring solutions might measure how often a particular resource is invoked. However, each invocation might require multiple functions, meaning you’re not getting a complete picture by simply measuring API calls. Macroservices make it more straightforward to keep track of traffic and what resources are being used, as multiple functions are bundled together and have more surface area to measure.

Security

Microservices can be a security risk, as well. Microservices are often distributed across multiple cloud platforms, resulting in increased risk and reduced visibility of individual components. Every microservice needs to communicate with external resources, as well, which also creates security risks. Finally, microservices rely on distributed data, which increases the likelihood of compromised data and data breaches. Macroservices reduce all of these risks. External interactions are minimized, and data is less vulnerable. Authentication is simpler as there’s less traffic coming from various points.

Simplifies Testing

Testing microservices has inherent challenges. Each microservice needs to be tested individually, for one. Different microservices can live on different servers, too, which can create problems with authorization and permissions. The services can shift between servers for each individual session, further complicating matters. Bundling services and functions into a macroservice helps make it easier to test them. It’s also easier and less time-consuming to set up permissions and authorizations.

Reduces Overkill

Scalability is one of the main selling points for microservices. While it’s important to be ready for anything, many applications will never become as big as Netflix, Amazon, or Uber. It’s simply not necessary to have everything decentralized and distributed across multiple servers and virtual environments. Adopting macroservices can help you keep the number, size, and scope of microservices to a minimum, so you’ll just have what you need. Best of all, macroservices are still adaptable, so they’re able to rise to unexpected surges in demand should the situation call for it.

Macroservices can also address some problems common to monolithic architecture, as noted by enterprise architect Pradeep Batchu. Modules can be decoupled from the macroservice to become their own independent entity, for one thing. Blue-green deployment can help to prevent brittleness or unexpected breakage by providing multiple development environments, thus making the whole system more robust.

Final Thoughts On Macroservices

As we have seen, there’s no single architectural style that’s perfect for every occasion. While there will always be trends and exciting and powerful new innovations and tools, you’ll get the most out of your projects when you spend time thinking deeply and critically about your particular needs.

With that in mind, macroservices reduce many common issues of using microservices. They’re also a useful transitional step between monolithic architecture and microservices. Therefore, it may be well worth it to spend some time getting comfortable with macroservices, even if you end up settling on a different architecture for a particular project.