Migrating Monolith To Microservices: What Pricing Model Is Applicable

When management decided to make drastic technology changes, the first thing it should be interested in is a commercial purpose. The second one — is a development price.

It concerns projects of any complexity, especially migration from monolith to microservices. The latter certainly delivers excellent results if the business requires transformation.

Fixed price is the most common model of cooperation between customers and suppliers. Enterprises also use the time-and-material method. So, you wonder which one is the most suitable for the migration process, and it's time to discover it.

Comparison Of Major Contract Types: Fixed Price vs. Time-And-Material

It is worth starting with the fixed price cost model definition, as it is the most widespread. It's a type of business relations that involves the initial approval of services and their cost with its subsequent consolidation in a service agreement. In other words, the vendor and the client accurately determine the services' nature and agree with the price at the very beginning of cooperation. Here all not-agreed extra costs a supplier should bear by itself.

Moderation in all things. This one is not an exception. So if a client wants to supplement requirements, it must expand the budget by the corresponding amount. Sometimes a vendor notices the necessity for extra investment. It must justify budget changes. When they are approved, the parties sign the additional agreements.

In this case, payments are periodic and usually dependent on milestones. They are directly proportional to the performed scope of work.

As seen, this model places a responsibility on a vendor. It should make a fair development project estimation. If the supplier overestimates the cost, the client may refuse its offer. But if the estimate will be lower than the actual price, the vendor will suffer, spending its resources for free.

Let's be honest customers love the fixed-price method and lobby it every time. Here are some reasons why:

• a client can correctly assess financial capabilities and lay the budget;

• it is a guarantee of quality current business' condition evaluation by the vendor;

• a customer is aware of the development deadlines and stages that minimizes additional control;

• the buyer relieves itself of almost all risks associated with excessive resource usage.

Looks pretty tempting, doesn't it? But this approach also has its drawbacks, like:

• the process inflexibility because of imperative and clearly defined conditions;

• high price since the vendor evaluates the entire development.

Now it’s time to consider alternatives. Time-and-material method is less famous but also convenient for usage. Here you don't find a fixed price for the entire project. A vendor and a buyer agree on an hourly rate for each involved specialist. A supplier charges all spent time within each milestone and sends invoices to a client.

This model provides the desired development flexibility. Sometimes it's necessary to change conditions within the development period to receive a flawless result. Here the shining example could be rapid business requirements updates because of unexpected changes in state legislation.

Moreover, a client can almost immediately check the vendor's expertise and assess how effort converges with the cost. If work-in-progress results do not meet the requirements, a client can change a vendor by providing the available base to another supplier for further improvement. Time-and-material method usage saves time because parties don't need to waste time defining a fixed cost amount. They can start to achieve goals at the very beginning.

But why is this method not as popular as the previous one? Most likely, the whole point is in the following shortcomings:

• the client cannot determine how much it should invest in the entire project;

• such cooperation requires permanent monitoring of the cost appropriateness;

• the unlimited client's ability to change the requirements harms the development cycle: no clearly defined goal means the absence of on-time quality results.

There is no winner in the fixed price project model vs. the time-and-material one battle. Some say they just fit different projects. The first method is perfect for small developments the second is for long-term cooperation. We have to disagree with it since a rational approach helps choose any suitable way, regardless of the project specifics. You will see why later. And now, let's move to microservices!

Migrating To Microservices In General

Earlier, we have written about what a microservice architecture is in detail. These are functional system units confronted with compactness and a high level of autonomy. One microservice is responsible for one business process. Such an approach enables a company to pay proper attention to any task. Core microservices' advantage is the ability to combine units developed on different stacks. Moreover, microservices are so adaptable and convenient to update. Firstly, it's because of the small amount of clean code, and secondly, because of the autonomy that allows engineers to ensure uninterrupted entire system operation and specific service updates simultaneously.

Migration to microservices from unwieldy monolithic systems is a laborious and time-consuming process. Although it is a trend now, not every enterprise needs migration. Despite their advantages, microservices are not a panacea. To understand whether they will help improve your business, learn the existing bottlenecks first.

But for what companies are migration suitable? - you might ask. There comes a moment when an enterprise operating with a monolith faces the issue of expensive and time-consuming feature implementation. It seems that an IT team begins to work on a "minefield" since any code change can lead to a non-rotating failure of the entire system.

That's why engineers strive to simplify these processes. Switching seems an appropriate option for it. Anyway, technical needs must be empowered by business ones. Management should define the commercial benefits of transformation and be willing to invest in it.

How To Migrate From Monolith To Microservices On Fixed Price Conditions

Migration to microservices on a fixed price basis is possible due to gradual movement towards achieving the goal. Of course, no one migrates half of the components in one go — it leads to unimaginable confusion. So, if we start the migration from bottlenecks transforming the entire system piece by piece, the fixed price model will work.

Anatoliy Medvedchuk, Software Architect at JEVERA

Migration to microservices is hardly a standard project. It is full of challenges and surprises that need to be addressed. Thus, it would be fair to classify switching as a complex development supporting digital transformation.

As you remember, there is an opinion that for complex tasks, the time-and-material pricing model is the most suitable. It isn't easy to disagree since it is more convenient to work on such conditions in this case.

But what about the fixed price method? Oddly enough, it can also be effectively applied if you properly prepare the ground.

Evgeniy Aleksandrenko, Digital Transformation Officer at JEVERA, shared the algorithm of both vendor's and customer's actions on which the fixed price cooperation success depends.

Step 1. Make a detailed description of the existing architecture and form a clear understanding of the system "as is". It is the principal for further correct separation of business processes on microservices. This first step is critical to a fair project estimation that is vital to maintaining healthy relations.

Step 2. Identify bottlenecks and prioritize their elimination. Usually, we are talking about the most unwieldy systems impacting commercial productivity. They have to be changed first. It is much easier if there is only one such bottleneck, but often there are several of them, so engineers have to prioritize.

Step 3. Determine the bigger picture "as is" and simulate the system "to be" as a result of development. Naturally, it's about a clear vision of how to transform a monolith into microservices. It is an arduous task, largely dependent on the vendor's creativity and attention to detail.

Step 4. Draw up a detailed roadmap reflecting the transfer process. Since the fixed price model is tied to milestones, it is the last but not least stage.

Thus, a business-friendly fixed-price model can work under any conditions. The biggest challenges here are: how to estimate the project, divide it into milestones with doable terms, and organize convenient communication between parties.