We continue to hold educational meetups for employees. Kirill, Team Lead of Crypton Studio, decided to hold a series of meetups dedicated to development. We share with you the short summary of the Microservice Architecture meetup. In the beginning, the speaker warned that this lecture is focused on employees who are not related to programming and development but want to know a little more. The main themes of the meetup were: – Differences between a monolithic solution and a microservice solution – Pros and cons of microservices – Do we need microservices? – Microservice system architecture – Deployment and technology Let's start with a monolithic architecture. The monolithic architecture is based on the fact that the service handles the business logic itself. There is one input and one business logic from the client interaction. The data in the monolith lie in one place - works without problems until user traffic grows. The data doesn't correlate with each other, but at some point, you need to get: payment data, my purchases, and other data. That's the added complexity of configuring the data. You have to think about how to layout the data for customers. Will these services communicate with each other only internally or will they be available as external API applications? There is no problem with communication in a monolithic solution because everything is written within a single code. But to test very important loose ends applications while they are in physically different places is difficult. Since services are up for the duration of the tests, communication is done, etc. If it's so complicated, why do it? So why do we need microservices? Microservice architecture is not used in all cases, as not all applications require such complexity. Service must: remain small enough be loosely connected to other services conform to the single-responsibility principle (SRP) principle The pros of a microservice solution: Reliability and fault tolerance Flexibility and scalability Security Rate of change and CI/CD Adequate cost of ownership Microservices communicate between services over the network. Architects consider the time it takes to get a response to make the application more fault-tolerant. Ways to communicate between services in a microservice solution: Synchronous calls Remote procedure call (RPC) Representational State Transfer (REST) Asynchronous messages Message Broker Webhook Microservices are more difficult to sustain. It is necessary to perform: Application infrastructure Development. Since the services are only linked to the database and not to each other - sustaining the work is difficult and costly. Deployment and execution. CI/CD (continuous integration and delivery) Application architecture Using microservices architecture, we solve the problem with load, performance, and the amount of client traffic that can be on the application: Definition of service Configuration approaches Communication between services Data External application APIs Logging and monitoring. The systems monitor the performance in real-time: they monitor the server load, and RAM, and there can be no errors in the logs. If there are errors, they notify and sound the alarm. — Application metrics — Detecting problems — Preventive — Actual — Audit easy to engage the developer in the project — Performing — Trace Testing — Unit Testing — Testing services — Based on consumer expectations — On the consumer side — Integration testing More resources are spent on microservices, which is not always a plus. For the reason that the project may not reach a large number of users over long distances, hence there is no point in designing the system. On most of our projects , we use a combination of a monolithic solution and a microservice architecture. For another example, we did one decentralized exchange using a smart contract on a monolithic solution. Previously, for a centralized BitTeam exchange , we used a monolithic solution, but the backend was overloaded, so it became necessary to redesign the service. It was difficult and painful, but now with the microservice architecture, the exchange is stable and easy to sustain. Kirill compared such practices to the broken windows theory . In criminology, the broken windows theory states that visible signs of crime, anti-social behavior, and civil disorder create an urban environment that encourages further crime and disorder, including serious crimes. And Kirill advised the developers: if you understand what you're doing badly - take the time to do better, and do not leave behind broken glass. The results are: Either microservice or monolithic have their place. Architects take into account all the features of the project, and only then do they make a decision. At the start, microservice is more expensive than monolithic. But supporting a monolithic solution will be more expensive in the long run. Also, after the meetup, employees asked questions and consulted based on their own experiences. Kirill's meetup was useful to everyone, from practicing developers to HR department employees. We are waiting for the next meetups! Share with us, were you interested? Should we keep continuing to share such information with you? Contact us and let’s start working together on your projects! https://crypton.studio