We recently had the privilege of hosting a webinar with Dor Atias, the VP of Engineering at Cycode. During our time together, he talked about an uncommon move Cycode made to ensure velocity and efficiency during their startup phase. Cycode decided to start with a Microservice architecture instead of a Monolith, from day one. Dor offered a few reasons explaining why every engineering team should start with Microservices if they can.
4 Reasons To Go With Microservices On Day 1
Ultimately, the decision will depend on your Minimum Viable Product (MVP) and current team. But if you can, you should highly consider going with Microservices. Here's why:
For Dor and the team, they saw that starting with a Monolith would ultimately hamper their agility.
Development speed is vital for any startup. You must ensure your MVP gets up and running as soon as possible. Your goal is to grow and begin generating revenue long before your seed money runs out.
According to Dor, having a Monolith may have helped in the first month or so as the product formed. But after that, it would take much longer to add changes and updates.
Adding a new feature to a Monolith requires fully understanding it. So when you bring in new developers or start developers on new projects, you have to train them on the entire monolith. All of this results in an exponentially longer onboarding and release cycle, especially as your Monolith grows.
While Microservices may require more effort to configure at the very start, they soon outpace Monoliths with independent roadmaps and deployment schedules. They can evolve with resilience due to the ability to test individual services and couple them loosely.
In a Microservices setup, developers "own" a single service or single set of services, which makes it easy for everyone to understand their responsibility within the development team. This is especially helpful in Cycode's decoupled service setup.
The sense of ownership makes it easier for developers to develop new features and services because they don't have to be proficient in every other service to update their own. They only need to understand dependencies and how certain services communicate. This also enables them to virtualize dependencies, update the service, and in theory, tell other developers how their downstream services will be affected.
Developer ownership also positively affects the way a team works through regressions and bugs. A service owner is responsible for making sure their service runs well and doesn't cause conflicts with other services. When it does, each developer makes the necessary changes for compatibility within their own service.
Faster Developer Onboarding
Microservices make onboarding much easier. Instead of training a new developer on the entire monolith, they only need to be trained on the specific services they will work with.
This reduces the time it takes to get new team members up to speed, which is necessary for a startup. It also reduces the time (and therefore money) spent training new members, freeing up the trainer to work in other areas and the new employee to start producing quicker.
In a Monolith situation, it takes longer to train new employees. It is also harder to trust them with big projects at first because their work affects the entire Monolith as opposed to a small number of services.
Finally, changes in a Microservice setup are usually implemented more quickly, making development more cost-effective. It takes far fewer person-hours to make an effective change, which means your time and employee budget gets maximal use.
With Monoliths, you may need to mock the entire interface or bring it down for a time in order to test and implement updates. In Microservices, only the dependent containers need to be mocked, and these mocks require fewer resources.
There is also a lower risk of unintended consequences coming with a change, thereby reducing your overall blast radius when a change is made. After all, every hour not spent fixing issues that arose due to an update is an hour that can be spent actually building your application.
Challenges of Microservices
This doesn't mean Microservices is the perfect approach. This architecture creates several hurdles to overcome:
- Microservices require communication between services. It may also be harder to see how different services interact without the proper analysis and UI.
- Microservices also requires service owners to communicate with one another to ensure less conflict. Some organizations develop an SOP or common template for building and deploying services to combat this, but that in itself requires time and energy.
- Oftentimes, the number of services grows to the point where additional software is needed to orchestrate, such as Kubernetes.
- Then, of course, tests can become harder to generate and update, especially as the number of services grows (as they will in most thriving startups). Cycode addresses some of these challenges using our contract testing platform, UP9, which we cover in a separate post.
UP9 is a microservice testing platform for Cloud Native systems that can scale across any number of services. UP9 helps developers prevent software regressions and increase engineering productivity through effortless testing and instant virtualization.
- Understand how services interact with each other with automatic contract discovery.
- Ensure system-wide contract adherence with tests that write themselves.
- Start testing early with test environments as code, automatically mocking all service dependencies.
- UP9 offloads the microservice testing workload from developers, giving them precious time back.
You can sign up now for free!