What are Microservices?
In the old "monolithic" manner of software development, an application lived in one place, was sold in a box, and support was offered as required. In microservices, we break the component parts down into individual services- microservices- and spin them up as containers in the cloud. A container is an application with its runtime requirements included in the package, like a virtual machine. We then use an API gateway to orchestrate all of these services into a distributed system (service-oriented architecture, or SOA), and accept requests from the front-end client. This part requires rigorous engineering by devops to reduce round trips, decrease latency, and increase API security at public-facing endpoints. It will also require API testing to ensure all of our microservices are operating as a team with load balancing, continuous integration, and continuous delivery. Once we're done, we will have an application that lives across many clusters, with minimal creation of new code on our part. We've just used what already works, and made it work in harmony. It'd probably look like this.
What is an API?
An API, or Application Programming Interface, is a set of rules that define how computers and applications can communicate with each other. If you recall the old switchboards that operators used to field phone calls to their destinations, APIs are a little like that. A client makes an HTTP request to an API at an _endpoint_ which it has access to. The API validates the request and passes the request to the destination server or program. The server sends a response back, first through the API, which then transfers it back to the client. The API provides security by decoupling the consuming application from the infrastructure providing the service. Once an API service and a client exchange authentication keys, they communicate through the API, meaning they don't have full access to each other, but enough information can be passed to get work done.
How Do APIs Work?
A client can issue certain kinds of requests (or HTTP "verbs"), of which there are four main types:
- GET - This request reads information from a record in the database.
- PUT- This request changes a record's information in the database.
- POST - This request creates a new record in the database.
- DELETE - This request removes a record from the database.
We will use IP Geolocation to GET a resource from their API.
Our GET request will retrieve information based on our IP address. We are telling the API with the request header we want all of the content, and it is returned as a JSON file, which is a lightweight text file popular in REST APIs.
In your terminal, enter `curl 'https://ipgeolocation.abstractapi.com/v1/?api_key={YOUR API KEY}'`. You should get output similar to below:
See the status code of `200`? You have completed your first GET request!
This is how information is exchanged in REST APIs.
Microservices vs APIs
With the use case above, we found the geolocation of an IP with just a GET request to an API. We didn't have to write anything new or reinvent the wheel. Now, imagine a whole application built with APIs- that's what microservices are. If we wanted to build a web sales site, we'd spin up web services for payment, catalogue, and inventory, and orchestrate their interactions via APIs. API contracts define what the API will do and what kind of requests and responses it will issue. So, if a customer finds an item they like in the catalogue (one service), they buy it via the payment microservice (second service), which then tells inventory (third service) that we have one less of that item. We could also build webhooks into this interaction.
Conclusion
Microservices are an architectural style, and they are executed with APIs. Without the interfaces and contracts APIs provide, we'd still be in the monolithic age, with our application in one place. Microservices orchestration is complex, but the advantages are many. One of the biggest advantages to service oriented architecture is scalability. Not only can one service scale independently in cases of high load, agile teams can also work on services separately of each other, then orchestrate them to work together.
