Building a software platform is no simple task, but it’s not impossible to accomplish with a small team and a solid strategy.

Over the next few posts we’ll discuss a few ways to position your software platform strategy for success when taking on this daunting task. Primarily, we’ll discuss:

  1. The application continuum
  2. Domain boundaries
  3. Infrastructure choices

Our End to End Guide to Product DevelopmentGetting Started: Microservices or Monoliths?

With the explosion of interest in microservices over the past few years, it’s not hard to stumble across strong opinions around them. Typically the debate is choosing between a microservice oriented architecture or a monolithic one when building out your software platform strategy or service offering. From detailed blog posts, to Venn diagrams, to comparison charts, people explain the tradeoffs that come with each choice.

However, from our experience it’s rare to find a solution that truly fits the exact definition of either. Typically solutions we’ve dealt with live in a gray area where they aren’t exactly monoliths, but at the same time they wouldn’t be classified as microservices. Perhaps they have a few external services, or some event driven functionality by a 3rd party, or they have some remote services, but don’t deal with circuit breaking, service discovery, etc.

Furthermore, these solutions pivot and shift over time so what we may classify as a monolithic architecture today might evolve into a microservice solution in a few months. And in rare circumstances, a few services might be aggregated back into a single application. So instead of viewing your solution as a static destination, understanding where you begin is most likely not where you’ll stay. As your application increases or decreases in complexity to support business demands, it moves along an axis of complexity commonly referred to as the “application continuum”, which was coined by Mike Barinek.

What is the application continuum and why do we care?

The application continuum serves as a guide of where to start building a solution based on the information you have of your current business.  

On the far left of the spectrum you have an unstructured approach. Think of a small program with a few dozen lines of code. Next you have your traditional application, perhaps an MVC architecture. It has models, views, controllers, and perhaps even interacts with a database.  

As you keep moving along this continuum you start establishing domain boundaries or “context” of how you work with your data and business processes. For example, you might have a user component providing specific services for users. As your solution’s complexity grows, you keep along the application continuum. Perhaps the next evolution in your solution breaks a few pieces of business logic into utility services or leverage 3rd party integrations. You might even have one to two services separated out to deal with heavier loads. Finally, on the far right of the application continuum you’re dealing with separate applications that deal with their own domains, datastores, libraries, etc (microservices).

What’s important to understand about the application continuum is you are not making a permanent choice on your architecture. Perhaps a monolith satisfies your current requirements, but there’s no reason it can’t evolve into microservices down the road. Keeping this at the forefront of your mind when making implementation decisions helps significantly reduce costs and friction later on.

With this knowledge you might be asking, “Well that’s great, but how do I know where to start on this continuum? Do I jump straight into microservices or start with a monolith and evolve into one?”  

One of Dialexa’s core capabilities is working with our clients to understand their current business needs and processes through a discovery phase as they define their software platform strategy. Through these conversations and activities we can align on an execution strategy for success and agree on a starting point on the application continuum. One activity we commonly go through focuses on understanding a client’s current domain boundaries, which we’ll cover in our next post!

If you want to learn more about our own processes, check out our free ebook, New Product Development Process for Software.

Our End to End Guide to Product Development

Click to Comment