Microservices Have An Identity Crisis
This crisis has its roots in the misconstrue and flabby interpretations of SOA
Explore these posts before diving into this article.
Myth of monolithic monster - This article delves into helping you understand the true nature of monolithic systems. A clear comprehension of this is essential for discussing the next topic..
SOA is a victim of its era - In this article, I elucidate the evolutionary context of 'service orientation' and its development and deployment within enterprises of early 2000s. Pay attention to the definition of SOA.
"In this article, I aim to ground the discussion by determining whether microservices are a deliberate design strategy or a design outcome. If they are indeed an outcome, it's crucial to relate to and comprehend the design principles and strategies that underpin microservices."
Here's a definition of Microservices from the Open Group. However, I find that many definitions, including this one to some extent, found through a Google search are either superficial, struggle to explain adequately, or are presented through the lens of technologies, perpetuating the same old mistakes—defining Service-Oriented Architecture (SOA) through the narrow perspective of Enterprise Service Buses and SOAP protocols.
Let’s take step back and dive right in.
Champions and Cheerleaders
Every technology needs champions and cheerleaders. For microservices, these advocates often emerge from the realm of Web 2.0+. Web 2.0 businesses, born around the early 2000s (+/- 3 years), fervently embrace this concept. These businesses can be categorized as follows:
They typically emerge as technology-focused enterprises or are deeply rooted in technology-driven operations.
Their business scope is often narrow, centered around a singular product or service they offer.
Business strategy revolves primarily around the offered product, unbounded by pre-existing business contexts.
They exhibit a startup ethos, poised to evolve into established enterprises over time.
The startup nature enables a higher risk appetite, given the minimal existing brand capital.
With everything essentially starting from scratch, they gravitate towards trending technologies at the forefront of innovation as the cost of fitting the technology into an existing business architecture is nil or minimal. This also had the positive effect where all component and aspect of the system is designed to provide ultimate user experience.
Their market scope often extends beyond judicial, market, and industry boundaries, sometimes even surpassing the limits of planet Earth. This demands forward-thinking considerations for the elastic scalability of their system designs.
Their products or services enjoy wide availability on the Internet, an infrastructure known for its variability of quality of service in global commerce. These offerings are accessed through diverse devices, ranging from large to small, modern to outdated, all connected to the network. This reality underscores the need to prioritize their product/service resilience across different geographic regions.
The speed at which they introduce product features to the market is existential to the success of their business strategy, exemplified to an order of magnitude greater than that of a traditional enterprise. Consequently, they closely scrutinize the time and cost implications of change as crucial metrics.
For the purpose of our discussion, let's refer to these entities as WYTs (pronounced "wɪts")—short for Wild and Young Technology Companies. They stand in contrast to BITTs (pronounced "bits") - short for Businesses Innovating Through Technology, which represent traditional enterprises and other businesses that view technology as a capability multiplier rather than their primary business focus.
Napkin Architectures
WYTs have gained renown for their often-legendary tales of sketching out product architectures on a napkin.
This observation is pivotal because within WYTs, the concept of "architecture" isn't confined by existing business structures. In many cases, there isn't even an established business yet.
Startups, rightly so, prioritize crafting products that resonate with their users above all else. Consequently, these companies are structured around their products, delineating various functions, groups, and responsibilities—business architecture comes later.
This laser focus allows them to prioritize delivering the ultimate user experience, free from the integration challenges often encountered by BITTs.
In BITT environments, service architectures must be conceived and evolved around existing business architecture. They often needs to integrate with existing legacy systems for various needs - access to data, shared infrastructure, policy conformance etc.. Furthermore, integrating with legacy systems can compromise overall service quality, a risk WYTs rarely comes across.
Another crucial industry trend that coincided was the emergence and widespread adoption of the public cloud and Software-as-a-Service (SaaS) delivery model. WYTs have readily embraced this trend for reasons that are obvious but extend beyond the scope of this article.
WYTs prioritize high availability (HA) of their services, particularly because their SaaS delivery model often serves a user base dispersed globally. Meeting the demands of such a widespread user base, across the Internet—an infrastructure with no QoS guarantees—necessitates designing services that can scale effectively.
WYTs prioritize scalability due to the nature of the SaaS model, which can rapidly amplify service demands. Unlike BITTs, whose business footprint typically revolves around a localized end customer base, WYTs face the potential for explosive growth in service demands.
Take, for instance, a Business-to-Business (B2B) company like Stripe: while Stripe may have only one business as a service subscriber, every transaction processed by that business necessitates Stripe's service.
This dynamic compels WYTs to proactively address scaling challenges that BITTs may only encounter when expanding into a global market. Even then, the network effect experienced by WYTs is a unique challenge not commonly encountered by BITTs.
Tracing A Microservice Portraiture
Sketching the contours of a supposed microservice portrait can vary in subjectivity and scope, depending on whom you ask—WYTs or BITTs.
Let’s take a concrete example:
In a BITTs environment, a financial lender offering mortgage products (among others) might develop an application submission service that incorporates uploading functionality to support income verification, all as one service. Let's assume it's implemented as a RESTful service. For the financial lender, this service is considered "micro" enough. Given that the target Total Addressable Market (TAM) for the mortgage market over the next decade, estimated by the number of mortgage applications, is, let's say, 2 million. Moreover, the rate of acquiring new customers is significantly spaced out. Therefore, the "upload" function is essentially a component of the "mortgage application microservice. Additionally, in this scenario, this is a dedicated service for mortgage application submission, focusing solely on this indivisible business operation. This service operates as a black box, with well-defined service contracts in place - ticking all the boxes as how a microservice should be designed and implemented.
Conversely, in a WYTs environment, an "upload" function may warrant its own dedicated service, thereby becoming a more "micro-er" service. Consider, for instance, the image upload feature of a Twitter feed. This service operates within its own "micro-context," where uploaded images may require scaling to various dimensions (e.g., thumbnails) and initiating processes for copyright checks, all at scale and high availability. Given that the number of tweets per second can reach many thousands, it would be prudent for a WYT designing such a functionality to segregate it as a separate service.
In the BITT setting, all functions are consolidated into a single "micro" service tailored to support a singular business-domain context: mortgage application submission. In the WYT setting, the "upload" functionality stands as a distinct "micro" service apart from the "tweet" service, yet both remain aligned with a singular business-domain context: tweeting.
The essence of this narrative is clear: There is an invariable and transcending architectural design strategy between the above two scenarios. That is, both the implementations are “services” and their design philosophy is “Service Oriented“. Both of them are considered optimally refined to be called “micro“ in their business domain/context.
Service Refactoring
Service refactoring is a methodical approach to improve the composition of a service contract, driven by either semantic adjustments or the imperative to enhance overall Quality of Service (QoS), including scalability, high availability, and other operational imperatives.
This process can entail breaking down services into narrower scopes while preserving their intended service orientation. This may also entail entirely new service contracts or no change at all.
The more profound the refactoring, the finer the granularity of the services becomes.
A service contract encompasses specifications such as the service API interface and Service Level Agreements (SLAs).
The service consumers must anticipate the evolution of the offered service and its contract and access patterns. When a service evolves through refactoring, the newer version is delivered through a versioned URLs.
Microservices should not be viewed as a desired outcome or an end goal in themselves. Rather, they may emerge as a necessary outcome of service refactoring driven by the demands for quality of service enhancements or changes in domain contexts.
Emergence of more granular services as a result of a service design refactoring exercise comes at many costs and tradeoffs. Never underestimate them!.
Conclusion
Separation of concerns is a fundamental design principle, applicable whether you're developing a standard service or one labeled with the "micro" tag.
When services are defined in this way, the outcome is a atomic service that delivers a atomic business capability with required QoS.
A microservice is the result of service design refactoring, whether conducted proactively or retroactively in response to emerging requirements.
A microservice is a manifestation of a service-oriented architecture.
What, then, should be the foundational design strategy underlying service-oriented architecture, hence microservices, you might ask? The key lies in the concept of 'business-domain context.' Stay tuned for the next post.