Is Go language, microservices and DevOps a good company?
- Transfer
Hello, Habr!
We remind you that everyone can still buy an excellent book by Sam Newman " Creating Microservices ." Since this topic has more than justified our expectations, we continue to search for related literature and not so long ago drew attention to the book on programming microservices in Go language.
We found an interesting article with the rationale for this approach on the Agile Maverick blog, and we place its translation under the cat.
Enjoy reading!
Now everyone is talking about microservices and DevOps. Put these words in your profile - and you will immediately be besieged by recruiters. I visited several interesting microservice mitaps in Munich, and I was most surprised that this topic was most interesting in the Java and Scala communities. It was surprising because Java and Scala are very rich languages in which there is plenty to choose from.
When discussing microservices, it is often said that services should be small in order to reduce complexity and dependencies in the implementation. But the richer the programming language, the more diverse the dependencies there. This is especially true in Java, where a lot of code is inherited.
I understand microservice architecture in a more holistic way. I would say that the whole ecosystem should be simpler and more compact. Implementation is only one side of the coin. The other side is runtime and related frameworks. Here we come to the topic of DevOps - a philosophy that seeks to link these two sides together.
The Java virtual machine is optimized for working with long-running applications, it has one of the most sophisticated and intricate garbage collection systems. Used in combat conditions for more than 10 years. Nevertheless, when I see modern, highly accessible architectures, the question immediately arises: do long-playing applications be needed to implement the vast majority of existing services?
I will give an example. I participated in the development of an application for video encoding, and this application, as luck would have it, was supposed to work around the clock with minimal delay. We thought about stopping at a stable programming language like Java or writing an application in Go that used existing C libraries for encoding and decoding, but such a project could result in memory leaks. Finally, we decided to divide the application into various processes; the static backend almost did not change, because it transmitted information using a practically unchanged protocol, and we also had a functionally rich client part, where there was a risk of leaks. Both parts used shared memory. It turned out that the option is good. Since Go starts quickly, we restarted the client part once every ten seconds. It turned out
Over the years, Java has developed many non-trivial solutions - for example, the log4j framework for logging. Using container solutions like OpenShift, you can see that it’s now customary to work with stdout and stderr again. There is no need to implement sophisticated logging solutions at the language level. This example allows you to judge how DevOps and new runtime environments change the rules of the game.
A typical Go docker docker image is about 15 MB in size; Compare it with the Java JVM image, which is about 300 MB in size. The difference is 1 to 10. The Java JVM is optimized for economical memory consumption, but it still requires about 10 times more memory than Go.
There are not many inherited frameworks in Go, so there are usually few dependencies, and the dependency code is part of the binary file. Therefore, there is no need for complex tools like Maven. In a container environment, the release of a new image is necessary whenever one of the dependencies in the chain changes. So, in Java Java, we need to update such containers quite often. Even worse, addictions are usually hidden somewhere deep.
Java and Scala are languages for object oriented programming. But when working in relatively simple subject areas, such solutions seem rather expensive to me. The “flexible” aspect of the Go philosophy allows you to organize development not only no worse, but much more clearly.
Java is known for its huge pipeline and many continuous integration tools like the Jenkins that have evolved around this pipeline. In Go, pipelines are much shorter, simpler and faster - because we get binary files that are ready for execution.
In the 1990s, there was a real boom in Java application servers - it was believed that they would provide development independence from the operating system and hardware. Reading the JEE specification, we also counted on the simplicity of remote communications and component-oriented development. When I see a docker container running Java applications, I always think of the new version of EJB. In principle, the Java stack has not been simplified, but now it is packaged in a container. Such packaging is not given for nothing, since another level of complexity is added; You will get to know him as soon as you try to debug the network of such a docker container.
Go docker is an option for scaling services, but it does not save a complex runtime environment. If you have only one simple service, then simple Go binaries can be executed directly on the host. If we are talking about a more complex application, then you can put services, for example, in a container and run them in a PaaS environment like OpenShift. To test the service on the developer's laptop, a container is not needed, all sorts of magic associated with it, too.
Go is simple, and you learn it fast enough. Basic Go concepts are learned in just a week or two. Therefore, new colleagues can successfully study the implementation of services, and developers or operators can quickly fix bugs without being distracted from the main work, even if they did not implement these services. Autonomous teams are a good thing, but if you have only three colleagues, then it becomes really difficult to ensure round-the-clock accessibility.
Go, where there are not many options, helps those developers who haven’t written it themselves to quickly get used to the solution. No need to delve into the philosophy of development. Of course, you can always implement services in a simpler style in richer languages, for example, Java or Scala, but in this case you need to learn self-limitation, discuss all the details with the team - accordingly, the microservice architecture is surrounded by huge documentation.
It seems to me that Go is ideal for implementing microservices. Why is this language so slowly adopted in the developer community?
I think, just nobody likes sudden changes. We tried to change just one dimension in the multi-dimensional world of programming. This dimension is the size of the service. In my experience, changing one dimension is not enough for evolution to begin. Since all dimensions are interconnected, they affect each other. Having decided to simplify the application by redoing it in the form of microservices, we must also simplify the execution environment and the programming language we work with. Otherwise, we get only a new headache - for example, you will have to manage many JVMs at once, which take up a lot of memory space and start rather slowly. Or we get a lot of small object-oriented solutions that will be distributed, and therefore more complex. Finally, we are simply confused with the many services that make up a huge dependency tree.
In my opinion, without changing all the measurements at once, we are as if changing from a horse to a car, but we take a saddle and spurs with us.
Let's not just write microservices, but also adapt the entire architecture to them. Go is great for this. If the subject area of the service expands, you can always use Java or Scala additionally.
We remind you that everyone can still buy an excellent book by Sam Newman " Creating Microservices ." Since this topic has more than justified our expectations, we continue to search for related literature and not so long ago drew attention to the book on programming microservices in Go language.
We found an interesting article with the rationale for this approach on the Agile Maverick blog, and we place its translation under the cat.
Enjoy reading!
Now everyone is talking about microservices and DevOps. Put these words in your profile - and you will immediately be besieged by recruiters. I visited several interesting microservice mitaps in Munich, and I was most surprised that this topic was most interesting in the Java and Scala communities. It was surprising because Java and Scala are very rich languages in which there is plenty to choose from.
When discussing microservices, it is often said that services should be small in order to reduce complexity and dependencies in the implementation. But the richer the programming language, the more diverse the dependencies there. This is especially true in Java, where a lot of code is inherited.
I understand microservice architecture in a more holistic way. I would say that the whole ecosystem should be simpler and more compact. Implementation is only one side of the coin. The other side is runtime and related frameworks. Here we come to the topic of DevOps - a philosophy that seeks to link these two sides together.
The Java virtual machine is optimized for working with long-running applications, it has one of the most sophisticated and intricate garbage collection systems. Used in combat conditions for more than 10 years. Nevertheless, when I see modern, highly accessible architectures, the question immediately arises: do long-playing applications be needed to implement the vast majority of existing services?
I will give an example. I participated in the development of an application for video encoding, and this application, as luck would have it, was supposed to work around the clock with minimal delay. We thought about stopping at a stable programming language like Java or writing an application in Go that used existing C libraries for encoding and decoding, but such a project could result in memory leaks. Finally, we decided to divide the application into various processes; the static backend almost did not change, because it transmitted information using a practically unchanged protocol, and we also had a functionally rich client part, where there was a risk of leaks. Both parts used shared memory. It turned out that the option is good. Since Go starts quickly, we restarted the client part once every ten seconds. It turned out
Over the years, Java has developed many non-trivial solutions - for example, the log4j framework for logging. Using container solutions like OpenShift, you can see that it’s now customary to work with stdout and stderr again. There is no need to implement sophisticated logging solutions at the language level. This example allows you to judge how DevOps and new runtime environments change the rules of the game.
A typical Go docker docker image is about 15 MB in size; Compare it with the Java JVM image, which is about 300 MB in size. The difference is 1 to 10. The Java JVM is optimized for economical memory consumption, but it still requires about 10 times more memory than Go.
There are not many inherited frameworks in Go, so there are usually few dependencies, and the dependency code is part of the binary file. Therefore, there is no need for complex tools like Maven. In a container environment, the release of a new image is necessary whenever one of the dependencies in the chain changes. So, in Java Java, we need to update such containers quite often. Even worse, addictions are usually hidden somewhere deep.
Java and Scala are languages for object oriented programming. But when working in relatively simple subject areas, such solutions seem rather expensive to me. The “flexible” aspect of the Go philosophy allows you to organize development not only no worse, but much more clearly.
Java is known for its huge pipeline and many continuous integration tools like the Jenkins that have evolved around this pipeline. In Go, pipelines are much shorter, simpler and faster - because we get binary files that are ready for execution.
In the 1990s, there was a real boom in Java application servers - it was believed that they would provide development independence from the operating system and hardware. Reading the JEE specification, we also counted on the simplicity of remote communications and component-oriented development. When I see a docker container running Java applications, I always think of the new version of EJB. In principle, the Java stack has not been simplified, but now it is packaged in a container. Such packaging is not given for nothing, since another level of complexity is added; You will get to know him as soon as you try to debug the network of such a docker container.
Go docker is an option for scaling services, but it does not save a complex runtime environment. If you have only one simple service, then simple Go binaries can be executed directly on the host. If we are talking about a more complex application, then you can put services, for example, in a container and run them in a PaaS environment like OpenShift. To test the service on the developer's laptop, a container is not needed, all sorts of magic associated with it, too.
Go is simple, and you learn it fast enough. Basic Go concepts are learned in just a week or two. Therefore, new colleagues can successfully study the implementation of services, and developers or operators can quickly fix bugs without being distracted from the main work, even if they did not implement these services. Autonomous teams are a good thing, but if you have only three colleagues, then it becomes really difficult to ensure round-the-clock accessibility.
Go, where there are not many options, helps those developers who haven’t written it themselves to quickly get used to the solution. No need to delve into the philosophy of development. Of course, you can always implement services in a simpler style in richer languages, for example, Java or Scala, but in this case you need to learn self-limitation, discuss all the details with the team - accordingly, the microservice architecture is surrounded by huge documentation.
It seems to me that Go is ideal for implementing microservices. Why is this language so slowly adopted in the developer community?
I think, just nobody likes sudden changes. We tried to change just one dimension in the multi-dimensional world of programming. This dimension is the size of the service. In my experience, changing one dimension is not enough for evolution to begin. Since all dimensions are interconnected, they affect each other. Having decided to simplify the application by redoing it in the form of microservices, we must also simplify the execution environment and the programming language we work with. Otherwise, we get only a new headache - for example, you will have to manage many JVMs at once, which take up a lot of memory space and start rather slowly. Or we get a lot of small object-oriented solutions that will be distributed, and therefore more complex. Finally, we are simply confused with the many services that make up a huge dependency tree.
In my opinion, without changing all the measurements at once, we are as if changing from a horse to a car, but we take a saddle and spurs with us.
Let's not just write microservices, but also adapt the entire architecture to them. Go is great for this. If the subject area of the service expands, you can always use Java or Scala additionally.
Only registered users can participate in the survey. Please come in.
