What are Microservices?
The word “microservice” refers to the individual services in a microservice architecture. Microservice architecture is an architectural style for modern web apps where the functionality is broken up into smaller fragments, and this is normally the idea people are trying to convey when they talk about microservices.
Microservices are an example of Service-Oriented Architecture, or SOA, which has grown to be a popular alternative to the traditional approach of building singular, self-sufficient applications, which we call monoliths.
.
The reason microservices are all the rage right now is that they make it so much easier to develop, integrate, and maintain applications. This ultimately comes down to the fact that individual functionalities are treated separately, initially allowing you to build applications step-by-step, and later allowing you to work on each element separately (so you can add, improve, or fix without risking breaking the entire application).
Microservices are especially useful for larger companies since they allow teams to work on separate items without the need for any horribly complicated orchestration between them. As Amazon Web Services describes them:
Microservices foster an organization of small independent teams that take ownership of their services. Teams act within a small and well-understood bounded context, and they are empowered to work independently and quickly, thus shortening cycle times.
Of course, if you break an application up into parts, there comes a serious need for those parts to communicate with one another effectively, and this is what ties microservices to APIs…
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. – Martin Fowler, Author and Speaker
What Is an API?
API stands for Application Programming Interface, where the keyword is the interface. APIs are the doorways, so to speak, that allows developers to interact with an application.
APIs have been around since the dawn of computing, enabling computers to call repeat functions to decrease application bloat. When we discuss APIs in today’s digital economy, however, we’re typically talking about web APIs that facilitate B2B communication.
Broadly speaking, APIs allow developers internal and external to accomplish one of two things: access an application’s data, or use an application’s functionality. Ultimately, this is how the world’s electronics, applications, and web pages are linked up to communicate with one another and work together.
Things like using a social account to authenticate on a website, having the weather on your phone, being able to access Google maps from a separate application, or triggering Internet of Things devices — they all rely on APIs to function. – Bill Doerrfeld, Editor in Chief at Nordic APIs
While many APIs are created for third parties to make use of — so-called public APIs — the increasing popularity of microservice architecture has led to the creation of more and more private APIs. In this case, the APIs act as a lightweight solution for individual microservices to communicate with one another.
From a technical perspective, APIs usually send data by means of HTTP requests. These return a textual response, normally in JSON format, which developers can use as they please. Types of API design styles include REST, SOAP, GraphQL, gRPC, and others. Many use specification formats like OpenAPI, RAML, or AsyncAPI to define API interactions in human and machine-readable formats.
The Difference Between APIs and Microservices
By this point, you’re somewhat familiar with the concepts of both APIs and microservices. Now, let’s highlight the differences:
Microservices are an architectural style for web applications, where the functionality is divided up across small web services.
whereas
APIs are the frameworks through which developers can interact with a web application.
As we mentioned, there’s definitely an overlap between the two, since so many microservices use APIs to communicate between themselves.
What You Should Know About APIs and Microservices
If you’re not a techie, it’s probably not worth learning all the details about APIs and microservices. That said, you should know what APIs and microservices can offer for everyday enterprise.
Microservices are a popular way to build web applications now, for the reasons we outlined above. To recap, a microservice architecture makes it easier and faster to build and work on individual parts of an application, and thus the application as a whole.
The appeal of APIs is twofold for most enterprises, since APIs are often the medium of communication between microservices, but also because they can also be used to expose an application’s data and functionality to third parties, leading the way for powerful integrations.
API Gateway
An API gateway is an API management tool that sits between a client and a collection of backend services. An API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.
A reverse proxy is a server that sits in front of web servers and forwards client (e.g. web browser) requests to those web servers
In computer networks, a reverse proxy is the application that sits in front of back-end applications and forwards client requests to those applications. Reverse proxies help increase scalability, performance, resilience and security.(More details here –
What’s a proxy server?
A forward proxy, often called a proxy, proxy server, or web proxy, is a server that sits in front of a group of client machines. When those computers make requests to sites and services on the Internet, the proxy server intercepts those requests and then communicates with web servers on behalf of those clients, like a middleman.
For example, let’s name 3 computers involved in a typical forward proxy communication:
- A: This is a user’s home computer
- B: This is a forward proxy server
- C: This is a website’s origin server (where the website data is stored)
In a standard Internet communication, computer A would reach out directly to computer C, with the client sending requests to the origin server and the origin server responding to the client. When a forward proxy is in place, A will instead send requests to B, which will then forward the request to C. C will then send a response to B, which will forward the response back to A.
How is a reverse proxy different?
A reverse proxy is a server that sits in front of one or more web servers, intercepting requests from clients. This is different from a forward proxy, where the proxy sits in front of the clients. With a reverse proxy, when clients send requests to the origin server of a website, those requests are intercepted at the network edge by the reverse proxy server. The reverse proxy server will then send requests to and receive responses from the origin server.
The difference between a forward and reverse proxy is subtle but important. A simplified way to sum it up would be to say that a forward proxy sits in front of a client and ensures that no origin server ever communicates directly with that specific client. On the other hand, a reverse proxy sits in front of an origin server and ensures that no client ever communicates directly with that origin server.
Once again, let’s illustrate by naming the computers involved:
- D: Any number of users’ home computers
- E: This is a reverse proxy server
- F: One or more origin servers
Typically all requests from D would go directly to F, and F would send responses directly to D. With a reverse proxy, all requests from D will go directly to E, and E will send its requests to and receive responses from F. E will then pass along the appropriate responses to D.
Below we outline some of the benefits of a reverse proxy:
- Load balancing – A popular website that gets millions of users every day may not be able to handle all of its incoming site traffic with a single origin server. Instead, the site can be distributed among a pool of different servers, all handling requests for the same site. In this case, a reverse proxy can provide a load balancing solution which will distribute the incoming traffic evenly among the different servers to prevent any single server from becoming overloaded. In the event that a server fails completely, other servers can step up to handle the traffic.
- Protection from attacks – With a reverse proxy in place, a web site or service never needs to reveal the IP address of their origin server(s). This makes it much harder for attackers to leverage a targeted attack against them, such as a DDoS attack. Instead the attackers will only be able to target the reverse proxy, such as Cloudflare’s CDN, which will have tighter security and more resources to fend off a cyber attack.
- Global Server Load Balancing (GSLB) – In this form of load balancing, a website can be distributed on several servers around the globe and the reverse proxy will send clients to the server that’s geographically closest to them. This decreases the distances that requests and responses need to travel, minimizing load times.
- Caching – A reverse proxy can also cache content, resulting in faster performance. For example, if a user in Paris visits a reverse-proxied website with web servers in Los Angeles, the user might actually connect to a local reverse proxy server in Paris, which will then have to communicate with an origin server in L.A. The proxy server can then cache (or temporarily save) the response data. Subsequent Parisian users who browse the site will then get the locally cached version from the Parisian reverse proxy server, resulting in much faster performance.
- SSL encryption – Encrypting and decrypting SSL (or TLS) communications for each client can be computationally expensive for an origin server. A reverse proxy can be configured to decrypt all incoming requests and encrypt all outgoing responses, freeing up valuable resources on the origin server.
Reference source :What Is The Difference Between APIs and Microservices?
Source link