MSA as a Project

Have you ever heard of such a strange thing as “MSA as a Project”?

You look at the title and ask, "What nonsense is this?"

MSA, which is abbreviated as Microservice Architecture, has established itself as a great purpose for building services for several years. And in the future, the name may change and remain popular. Maybe.

Many companies’ development organizations are attempting MSA, but to be more general, there is a difference in the way MSA is solved. Let’s take our favorite quiz as an example. (There are two answers.)

1 + 4 =   5
2 + 5 = 12
3 + 6 = 21
8 +11 =  ?

If we can afford it, we can take our time and enjoy the process. However, in the case of business, things may be a little different. Like someone else, they check the answer first, understand the solution process, and look at the problem again. Yes, implementing MSA can be like this.

Outsourcing intent:

• The biggest advantage of outsourcing is that the company lightens the company by eliminating unnecessary organizations or organizations
• The advantage of being able to efficiently improve the organization so that the company can flexibly respond to the rapidly changing business environment
• Manufacturing process, HR, marketing, IT system

However, as the digital transformation flow and IT capabilities become important to the industry, the IT system turns to insourcing again.

Insourcing intent:

• Business control: The need for first-party employees to have complete control over key systems
• Internal competencies: Most effective when you already have a skill or competency or outweigh the additional overhead
• Internal customer satisfaction: Leading visibility into services and driving tasks

The difference comes from these two roots. Let's take two simple scenarios that come to mind.

Shall we take a look at the flow of insourcing? The IT organization’s goals and incentives have to overcome a situation of disparate dependence on opposing teams. It requires communication, integration, automation, and close collaboration among all the people required to plan, develop, test, deploy, release, and maintain a solution. A process that requires common management of each value throughout the entire process is also required. This is where a process for each team is created and something called DevOps or DevSecOps is created. Services created by each team are connected and finally, something called MSA is created. (Did I explain too easily?)

Many famous IT companies we know run MSAs. Numerous articles and resources say that MSA has been successful for business. Some companies looking at them here want to do the same, but they are short on manpower. This is how MSA starts with outsourcing. It's a project!

Approach it in a way that allows you to quickly adopt the benefits of MSA operations and design while retaining the benefits of traditional outsourcing. Conversion of one specific service or building a new service as an integration versus a gradual microservice-specific approach. Integrate the fragmentation of technologies and tools to form a coherent value chain as a team for service projects for consistent management and maintenance. A unified CI/CD design for microservices increases maintainability and reduces dependence on humans. IT organizations build workflows that adhere to cross-organizational governance for conflict resolution that relies on teams with different goals and incentives. It’s still a silo. In addition to the structure that is easy to scale out of microservices, the defined interfacing between services reduces errors and points of failure. It is a service with a solid composition for a single goal, and an internal structure prepared for future linkage with other services is created. Your MSA project has been successfully completed!

In fact, both of them must have good intentions. Latecomers who have confirmed the value of MSA also want to quickly adopt the culture and operation method. There are several challenges when doing the MSA as a Project.

Platform

• Started without know-how on containerization and management platform due to the vague need for containers when designing MSA
• Although we designed a container-oriented architecture, there are components that are difficult to containerize or have performance issues when configuring containers.
• Aiming for fault-tolerant, non-disruptive service, but no management orchestrator to support some legacy forms (VMs)
• When building on the public cloud, if the on-premises environment needs to be converted in the future, the entire conversion is not possible.
• Aiming to implement IaC, but delaying automation due to scheduling problems during prototyping configuration, subsequent tasks are also delayed continuously

Development Organization

• If you need to adopt a tool like Kubernetes, the burden of learning is high.
• Learning about network structure, storage, components for distribution, etc.
• Development in a conventional way can shorten development time, but the transition to containers is forced and delays occur.
• Even if the application on the cloud is autoscaling in units of VMs, there is a situation where you have to manually configure the related configuration in the front end of the network. (Infrastructure cooperation is required.)

It’s hard to say it’s easy, but here’s the story of a successful, short-lived, persistent MSA environment with Consul and Nomad.

Their existing environment was a three-tier configuration consisting of Tomcat and Oracle DB. Due to the high request peak at the time of the event, it was necessary to increase and decrease VMs every time, and at the same time, it took a lot of time to add new services to the existing application.

They saw small successes for MSA with Consul and Nomad and then expand to the cloud.

Lower the learning curve and focus on building MSA with a developer-friendly platform

• Developer understandable deployment settings rather than configuration files for the platform (e.g. Kubernetes)
• Selectively containerize and restructure applications composed of Nodejs (Vuejs), Java
• Container-like orchestration even for legacy applications (Java <= 1.8)

Deployment Orchestration

• Canary distribution is applied to the service, and API, CLI, and UI support actions for approval to link CI/CD
• Rolling and Blue/Green distribution applied
• API, CLI, and UI support the rollback function to the previous version in case of deployment failure.
• Increased responsiveness to failures with Auto Scaling and Auto Healing support

Gateway (Network middleware) Automation

• The creation and application of Nginx’s backend service list for Ingress is automated, taking advantage of MSA’s dynamic expansion.
• The contents of the created setting file can be applied at a level that the developer understands by supporting Template, Volume Mount, and Artifact download methods.

If the purpose of starting MSA as a Project is to focus on acquiring the know-how and value that an advanced insourcing-based company did, both small and large successes will be achieved.

Oh, the answer to the quiz earlier? 40 and 96.