For a while now we have started to hear about concepts like microservices architecture, some sort of version 2.0 of a distributed architecture. This type of architecture has been spurred on by the great boom in Cloud technologies, which fit perfectly with it.

In this article (divided into two posts, you can access the second part by clicking here) we try to identify who are the ‘’new kids in town’’ in this architecture and what part they play in it.

Most of the components of the architecture were originally developed by Netflix, the well-known online streaming site, which has the largest network downloading traffic in all of the USA (often representing a third of the total traffic). Netflix’s architecture is made up of more than 500 microservices and has more than 50 million subscriptions that make some 2,000 million requests every day.

Below we analyze a selection of the most important components of the previously mentioned architecture from three different angles, ‘What is it?’, ‘How does it work?’ and “What does it provide?”.

Eureka

What is it? Eureka is a server for the registration and location of microservices, load balancing and fault tolerance. Eureka’s job is to register the different instances of existing microservices, their location, condition, metadata…

How does it work? Each microservice will communicate with the Eureka server while starting, in order to notify that it’s available, where it’s located, its metadata…. In this way Eureka will keep the information of all the ecosystem microservices in its register. The new microservice will continue notifying Eureka of its condition every 30 seconds, which we refer to as ‘heartbeats’. If after 3 periods Eureka still hasn't received a notification from this microservice it will be eliminated from the register. Likewise once Eureka receives three notifications it will consider the service available once again.

Each client of Eureka can also recover the register in order to locate other microservices with which it needs to communicate. The register’s information is stored in the client’s cache. Eureka can be configured to work in cluster mode where various ‘’peer’’ instances will interchange their information. This, together with the register’s information stored in the client’s cache gives Eureka a high fault tolerance.

What does it provide?

• Abstraction of the microserver’s physical location: any microserver that is a Eureka client only needs to know the ID of the microserver it wants to call on and Eureka will determine its location, port…

• To know the state of our microservice ecosystem: Eureka provides a dashboard that allows you to see the existing microservices currently in the register.

• You can configure it as a cluster giving it a higher fault tolerance.
• Eureka provides multi-region support defining different groups of microservices.

• Eureka was initially developed by Netflix, which uses AWS as IaaS, so it was designed to easily integrate with Amazon services.

• Eureka integrates with Asgardto carry out deployments, making the change to new or old realeases easier.

Cloud-config

What is it? Cloud-­config is a configuration server thought for distributed systems. Its job is to store the ecostystem’s microservices configuration properties.

How does it work? Cloud-config stores configuration properties in a git by default. While starting, a microservice will consult the associated properties to the cloud­-config server which will download them from the git repository. The whole process is carried out transparently without a single code line.

The property files will traditionally be named with the format {microservice}–{profile}.{yml|properties} where ‘microservice’ is the identifier of the said microservice and ‘profile’ a Spring profile.

What does it provide?

• Cloud-­config integrates with Eureka so that when the microservice starts, if an Eureka client, it will consult the Eureka server about the location of the configuration server and will ask for its configuration.
• Storing the configuration in a git repository allows us to have not only a centralized configuration repository but an archive of it. Besides, cloud-­config adds features to the integration with git allowing us to consult different branch configurations.
• It allows us to manage the configuration of different environments, label it and consult it by labels.
• It provides optional encryption for the values of properties.
• The existence of certain spring annotations when integrated with clound-config allows us to recreate beans and restart the whole spring context. This allows microservices to adapt to changes in properties.