In the industry today there are a few different ‘buzz-words’ that are being thrown around, one of these is micro-services. At Microsoft Connect() event a couple of weeks ago, we heard a lot about these. Not to mention that by following the .Net GitHub check-ins we are seeing some really amazing support coming for Docker and Service Discovery.
These started out as an architectural change in thinking. In the past, companies developed large, intertwined systems. The idea for most of those developers, was deployment. It was much easier to build and deploy a single package. It had all of its business and data classes built inside it. There is always a cozy feeling when your package contains everything it needs to serve your clients!
One of the main issues with this way of development is that making changes and deploying them become more complex. In the logical thinker this may make sense, one deployment and it’s wholly self-contained. The issue however, is that these systems are large, and they take a lot of time to compile and deploy. Hence you have a noticeable outage on the servers that you are deploying to!
With a micro-service you have many issues while architecting for success, however you can deploy many versions and control the deployments and updates much easier. Not to mention testing and deployment are quick and precise.
The philosophy is that you will break down your system to its smallest component. Create that component, and replace the calls to that within your monolithic system. The change within your architecture is massive! There are many issues that are not thought about that will jump out as you continue your journey to creating a great Service Oriented Architecture or SOA.
I’ll start out with saying that ‘micro-services’ are not a new invention. This is what the basis of SOA is! Breaking down your components to their lowest level, and then creating something that specialized in that task. For example, if you are creating the standard e-commerce site, you should create a user service. Of course you will have to also login to the site, so you would need an authorization service as well. This service would call the User service to garner the user data. (See below).
As you all see this is an easy way to create and build your architecture. The issue is that in the REAL world, this demo style code won’t scale! The authorization service would have to know exactly how to communicate with the user service. Not to mention the API gateway would also have to know how to communicate with both services are as well!
To scale micro-services you must have some middleware to allow the services to report when they come online, and when they are offline. Not to mention the ability to scale up and handle many requests. When you implement this type of architecture there are a couple of ways at this point. Utilizing third-party products like NginX and Consul, or within Azure; Traffic Manager. I’ll touch on this in a future blog post, but what is needed in the long run is to allow multiple services to run upon a machine; or preferably a group of machines. How many? This is a more difficult question to answer, but as many as possible without taxing the machine they are executing upon! This could be as few as 1.
To allow many services to execute upon a single machine, you have to utilize multiple ports, and by doing that, somehow you have to allow a client service to find and communicate with your service. To allow this to happen you will need 3 points of information. Searchable service name
- Searchable Service Name
- Service Endpoint
- Service Port
By having these items any client service can find, and communicate with your service.
Let’s get started with these posts and build a working micro-service and a client that utilizes it!