Considerations When Adopting Microservices Architecture in Greenfield Projects
Nov 12

Considerations When Adopting Microservices Architecture in Greenfield Projects

Launching a new business or project means that everything has to be built from the ground up, from defining services, functions and product range, to deciding the technology, infrastructure, and resources required. Enterprises, to serve the evolving demands of customers and add business value, are looking to develop new applications faster with minimal resources and cost. 

In greenfield development projects, the new applications built either solve unaddressed business challenges or entirely replace an existing inadequate system. Consider this example of a new start-up company that is going to launch an online, product range. The primary focus of the company is to build a minimal viable product (MVP) with the ability to make product improvements from customer responses. Without existing systems or architecture in place, the company plans to build a suite of applications to serve various business needs, add new functions, provide an uninterrupted online presence, and ensure scalability based on changing customer demands. 

The company, with the absence of an existing legacy system, is weighing out the option of adopting microservices. If they choose microservices architecture, this would involve defining service boundaries (which need to be dynamic) and deciding the technology stack for each microservice. It would also include rethinking operations, creating a scaling strategy, provisioning infrastructure required for elastic scalability, and configuring and maintaining monitoring solutions. 

While it is a relief not to inherit technical debt from legacy systems, there are many aspects to be considered when adopting microservices architecture for a greenfield development project.

Define your domain or service boundaries

When developing greenfield applications, defining service boundaries could be tricky. Before trying to categorize your system into different services, ensure you know your domain. For instance, you define that service A is responsible for doing a particular function. What if this changes or if you realize the function needs access to service B. 

Before separating functions into microservices, you need to understand and have clarity about the dependencies they have. Only after some time would patterns emerge from which you can identify the functions and services and the problems they can solve. However, there would be apparent functions such as login or profile services that could be carved out into a microservice straight away. 

Decide on the technology stack

The technology stack that used with microservices in greenfield projects is diverse. You can combine multiple programming languages, frameworks, and data storage technologies. However, standardization becomes an issue with different teams using an entirely different technology stack. Low-code platforms offer one point of control for application updates and maintenance to overcome technology diversity. With a centralized repository for version control, multiple developers can collaborate and merge changes.

Achieve a minimum level of operational readiness

To start a greenfield project using microservices architecture requires a minimum level of operational readiness maturity. Operational readiness in terms of ensuring there is access to a deployment environment and building continuous delivery pipelines where services are created, tested, and deployed. Whether it is identifying and provisioning infrastructure requirements, scaling strategy, and service discovery, you need to have a plan to address the operational complexities that could occur when adopting microservices architecture.

Low-code platforms simplify application development, deployment, and delivery. They use Continuous Integration (CI) tools like Jenkins to provide a continuous delivery pipeline and provide an automated containerization workflow. Low-code platforms transform the way enterprise applications are developed and delivered.

Reorganize development, DevOps and IT teams

To ensure every microservice is managed independently, you would need to reorganize your teams and maintain a balance of resources. It is not productive to have engineers working on multiple microservices; neither is it feasible to have one person for each unique role. For instance, a DevOps engineer can manage dual roles of development and operations, or a full-stack developer can manage the entire application development lifecycle. Ideally, every team should have a balance of expertise which could comprise of developers, testers, operations engineers, database administrators, UX designers, and in some instances, even product managers. 

With the rapid increase in opportunities applications have to serve customer needs, development teams are under pressure to deliver at a fast pace with tight turnaround times. Added to that, the shortage of skilled professionals is hindering rapid application development. Here is where low-code platforms help by providing a user-friendly interface and a development environment where teams can collaborate on modules with efficiency.

Ensure microservices implementations do not turn into distributed monoliths

There are whispers about how most greenfield microservices implementations turn into “distributed monoliths.” By taking a monolithic codebase and spreading it across a network, the benefits of microservices architecture fade. For instance, when making changes to business logic in a shared library, if you need to synchronize the deployments of multiple teams, it reflects the inability to deploy changes in isolation. When building a new system, it is a huge advantage to have a single, non-distributed codebase. 

In greenfield, microservices-based implementations, low-code platforms provide the business agility by automating systems and ensure data security, integrity, and compliance with IT governance and standards. However, before going all in to adopt microservices architecture, it would be useful to be clear about the fundamental aspects mentioned earlier about service boundaries, infrastructure, technology stack, resources, and team organization.

About The Author

Leave a reply

Your email address will not be published. Required fields are marked *

We use cookies to provide you with a better experience. By using our website you agree to the use of cookies as described in our Privacy Policy. Continue