In this entry, Martin Fowler graces us with his lectures once more, this time, we take a dive into Microservices.
So, microservices seems like the new kid in town (despite being involved in development processes that go as far back as the development of Unix), with it's current use in many industries. The question here is, what is it? Is it an architecture? The basic description is that microservices is a compilation of many different services working in tangent to deliver a working application. Everything is located in its corresponding node, and the program works as a whole via node communication and collaboration.
In a way, microservices has been compared to the Monolithic architecture, every "node" is bundled up together, and you can edit each node independently, and all of it is connected to the database. The program would be, of course, that any and all changes would involve the modification of the entire monolith.
The advantage that microservices has is it's versatility to work together, while at the same time allowing programmers to focus on different areas, using different languages. I think where I see this most often, in my short experience as a programmer, would have to be full-stack development. Perhaps it doesn't quite fall under the category of microservices, I wouldn't be too sure, but their are certainly some parallels to be traced.
If you're working on the database, you focus on the CRUD. You don't really have to worry about how the website will be displayed, or how the user will interact. All you really care about is how efficient the database management is going to be. Such would be the case with Node. Once you obtain a query, you cast it towards the front, answering the GET. Meanwhile, another team can worry about the page's functionality, and how it will display the user's queries back to them.
This is obviously a small example, but I do find at least a bit accurate. All in all, microservices seems quite comfortable, if AWS keeps succeeding, it may grow at an even faster rate.
So, microservices seems like the new kid in town (despite being involved in development processes that go as far back as the development of Unix), with it's current use in many industries. The question here is, what is it? Is it an architecture? The basic description is that microservices is a compilation of many different services working in tangent to deliver a working application. Everything is located in its corresponding node, and the program works as a whole via node communication and collaboration.
In a way, microservices has been compared to the Monolithic architecture, every "node" is bundled up together, and you can edit each node independently, and all of it is connected to the database. The program would be, of course, that any and all changes would involve the modification of the entire monolith.
The advantage that microservices has is it's versatility to work together, while at the same time allowing programmers to focus on different areas, using different languages. I think where I see this most often, in my short experience as a programmer, would have to be full-stack development. Perhaps it doesn't quite fall under the category of microservices, I wouldn't be too sure, but their are certainly some parallels to be traced.
If you're working on the database, you focus on the CRUD. You don't really have to worry about how the website will be displayed, or how the user will interact. All you really care about is how efficient the database management is going to be. Such would be the case with Node. Once you obtain a query, you cast it towards the front, answering the GET. Meanwhile, another team can worry about the page's functionality, and how it will display the user's queries back to them.
This is obviously a small example, but I do find at least a bit accurate. All in all, microservices seems quite comfortable, if AWS keeps succeeding, it may grow at an even faster rate.
Comments
Post a Comment