Microservices (aka the microservice architecture) is an architectural style that structures an application as a collection of loosely coupled services. The microservice architecture enables the continuous delivery/deployment of large, complex applications and enables faster, better delivery of value to implement business capabilities, thus enabling an organization to evolve its technology stack.
It enables organizations to scale their products and add or adapt services efficiently. Companies can deliver software faster and more efficiently in order to compete in the dynamic markets of today and tomorrow, while at the same time keeping their products fast, secure, and stable.
Lately, microservices have gained far more attention due to their use as the architecture pattern of choice at companies such as Google, Facebook, Twitter, Netflix and many more prominent technology companies and startups.
Some of the useful tools/techniques used while developing solution in Microservice Architecture:
• Use an obscure but cool communication protocol, use HTTP and REST. They are fast, reliable, easy to implement, and very easy to debug. If you need to increase the security, implement SSL/TSL
• We are decomposing an application into small parts which we want to scale and deploy independently, so it makes sense to keep the source in different repositories. Having different build environments and repositories means that each microservice has its own lifecycle and can be deployed without affecting the rest of your application.
• We can use Telemetry (it is a system that gets the stats from the container) and autodiscovery (it is a system that helps us to see which containers are working properly) to supervise the container ecosystem.
• Given the advantages provided by the virtualization and containerization, nowadays using containers in the development of an application based on microservices is a default standard. There are multiple containerization projects, but the most used and supported is Docker.
• Autodiscovery is a mechanism in which we don't specify the endpoints of each of our microservices. Each one of our services use a shared registry in which they say that they are available. When a microservice needs to know the location of another microservice, it can consult our autodiscovery registry to know the required endpoint
• Since our application will be using an autodiscovery pattern, we need an easy way of dealing with the service registering, deregistering, and health check. One of the simplest and fastest applications you can use is ContainerPilot, a small micro-orchestration application that works with Docker compose. This small app is being executed as PID 1 and forks the application we want to run inside the container.
• To unify the way any client uses our microservices, we will be adding an extra layer–an API gateway. This API gateway becomes the single entry point for any client (for example, browser and native application). In this layer, our gateway can handle the request in two ways: some requests are simply proxied and others are fanned out to multiple services. We can even use this API gateway as a security layer, checking whether each request from the client is allowed to use our microservices or not.
• Each of our services will obtain the location of all the other linked services by querying our service registry (a place where we store information about all our services using Consul). Our registry will know the locations of each service instance.