Making Microservices Just the Right Size [MDB Weekly]

First Up: Coming soon: Basics of Cloud Security

February 28th is coming up fast! That’s the day my latest course,?Basics of Cloud Security, will be available at the?Atchison Academy.?

How do you keep your private data safe in the public cloud? Is it even possible? In fact, your data and your application is likely safer in the public cloud than in your own private data center. This course will show you, at a high level, the guiding principles and policies you need to understand to keep your cloud-based and cloud-native application safe and secure.

This course is designed for technical executives, managers, and leaders that want to understand, at a high level, how to build a safe and secure cloud application. It’s also for cloud architects and senior developers that want to understand how to communicate basic cloud security principles to your company’s executives and leaders.

The course is delivered as a series of 15 lessons sent via email, one lesson per day. At the end of the course, you can take an optional quiz, and if you pass, you’ll receive a completion certificate.

Check it out — Launch date is Feb 28

Last week’s top story:?Making Microservices Just the Right Size

Building cloud-native applications involve building an application as a series of microservices. The idea is that individual microservices are self-contained slices of an application that can be designed, built, and operated independently of the rest of the application. This allows large and complex applications to be managed in bite-sized pieces, where each piece is built and operated by a single development team.

But microservices come in various sizes, from tiny, super-specialized microservices, to services big and complex enough to form their own monolithic applications.

It’s difficult to determine the right size for services you need to build your organization’s apps and meet your business goals.

SERVICES VARY IN SIZE

Historically, services tended to be rather large and could form “mini-applications” on their own. In fact, even a massive monolithic application can be, to some extent, a service for other systems. Many early SaaS (Software as a Service) systems were built as large monoliths—often a simple Ruby on Rails stack—yet to their customers, they were simply a single “service” in their distributed application.

With the advent of cloud-native architectures, however, there has been a drive to make services smaller and simpler. The idea is that smaller services are easier to understand and easier to manage, debug, and update. They can be owned and maintained by a smaller team. Since the architecture of an individual service is much simpler, they are easier to understand. Simpler services mean fewer bugs and are less likely to cause problems during upgrades.

In theory, the smaller you make the service, the easier they are to manage. So goes the theory.

There is a fundamental issue, though, with this “smaller is better” approach in practice. The smaller you make your services, the more services you need to build an application with a given set of features and capabilities. The more services you have, the more complex the interconnection is between the services and hence the more complex the overall system architecture is.

By attempting to make smaller and, therefore, simpler services, applications have become more complex. The smaller service size is a great benefit to the individual development team that owns that service, but the complex interconnection between services has made the overall system architecture more involved.

We’ve essentially moved the complexity uphill. Rather than individual developers dealing with complexity at the code level, system architects have had to deal with the complexity at the system level.

How do we determine the ideal size—The Goldilocks Size—for our services?

Read the suggestions in Container Journal

Also Last Week: Missing out on insights?

Are you subscribed to our email newsletter? If not, you miss out on some great insights—Modern Digital Business Insights. Thursdays are insights days. Every two weeks or so, on Thursdays, you’ll receive an article of interest to those building, operating, managing, scaling, and maintaining modern digital businesses based on modern applications at scale.

Plus, you’ll receive this newsletter — The MDB Daily Newsletter — delivered to your inbox each Monday morning.

Joining is absolutely free, plus you’ll receive a?chance to win?a free copy of one of my books,?Architecting for Scale, or?Overcoming IT Complexity, signed by me.

Join Modern Digital Business Insights