2. API Architecture

APIs are an interface to external world for the services offered by organization. They interwork with each other to deliver complex functionalities. It uses simpler protocols and provides more sophistication around the exposure itself, including developer portals, policy controls, and self-administration.

In current context, APIs are tightly coupled with the business logic, which could be reusable component. This causes, difficulty in making quick changes in the APIs and business logic, as the whole sub-system has to go through the elaborate release processes for complete system. Also, fault in one of the pieces of complex business logic can lead to the failure of complete service. Such tightly coupled systems are known as monolithic designs.

Modern day Internet organizations have solved this problem by taking away business logic from APIs and converting them into microservices, which evolve independently, while providing reusable functionality to all the systems, very small code base, easy to deploy,change and support. These are available as plug-and-play components to create new APIs at API gateways.

2.1 What is an API gateway?

API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. With a few clicks in the Management Console, you can create an API that acts as a “front door” for applications to access data, business logic, or functionality from your back-end services, such as workloads running on cloud or any Web application. The API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management.

Working with a microservices API gateway can greatly reduce coding efforts, make applications far more efficient. The benefits of Microservices architecture are realized over a period of time.

2.2 What are Micro services?

The concept is about building an application consisting of many small services that can be independently deployed and maintained. They own and do not share their data. They don’t have any dependencies but rather communicate with each other through lightweight mechanisms (typically not HTTP, but sockets) and lack a centralized infrastructure. It is even possible to write these small (micro-) services each in its own programing language. Diagram below compares at high level key difference between monolithic and micro-service architecture. Elastic infrastructure should help take away the issue of scalability across several microservices in the system.

2.2.1 Benefits of microservices

  • Agility: By breaking down functionality to the most basic level and then abstracting the related services, DevOpscan focus on only updating the relevant pieces of an application. This removes the painful process of integration normally associated with monolithic applications. Microservices speed development, turning it into a processes that can be accomplished in weeks and not months.
  • Efficiency: Leveraging a microservices based architecture can result in far more efficient use of code and underlying infrastructure. It is not uncommon to experience significant cost savings by as much as 50% by reducing the amount of infrastructure required to run a given application. 
  • Resiliency: By dispersing functionality across multiple services eliminates an applications susceptibility to a single point of failure. Resulting in applications which can perform better, experience less downtime and can scale on demand. 
  • Revenue: Faster iterations and decreased downtime can increase revenue (either using athrough efficiencies created via a chargeback ideology, or by improving user engagement). User retention and engagement increases with continuous improvements offered by microservices.  

It brings us to five key areas for Services, which are explained in following sections:

2.1 Service Boundaries

Service :- It is a technical authority for specific business capability. It should contain all data and business rules within it.

As we moved towards microservices architecture it becomes very important to define service capabilities.What a service can and cannot do.So in this section we will see how to define service boundaries and what are the attributes of a service.

2.1.1 What is not a service?

Following are important points to keep in mind while defining a service

  • database should not be made a service
  • If service do not have data, then it is just a function
  • Services own their data

2.1.2 Finding Service Boundaries

2.1.2.1 Services should own their data

While it is said above that every service should have their own data, following rules may be observed in this context :

  • Minimize the coupling between services. It should not lead to corruption of each other’s database
  • The micro-service can have ownership of a simple columnar database containing the identifier and the respective attributes value.
  • services should keep their data in the same shared database as long as each service has its own schema.

2.1.2.2 Services should remain the authoritative source of data even across systems

Enterprises may build multiple systems ,back-end, desktop, mobile, etc. accessing the same data. same services should provide their respective business capabilities for all of these systems. Although the systems may be built using different technologies and languages, they should share the same services.

2.1.2.3 Services should share some contract across system

Any service we write should have some kind of contract related to it.That contract should mention what is the input and output of that particular service.Services will share this contract between them and if any service violets this contract then it should be marked as invalid.

2.1.3 References

Lego based Infrastructure - Its the Future supporting the new Microservices Architecture

2.1.3.1 Websites

2.1.3.2 Videos

2.1.3.3 Gurus and Their Blogs

2.2 Event Driven Architecture

2.1 What is an Event?

An event is a notable thing that happens inside or outside your business. An event (business or system) may signify a problem or impending problem, an opportunity, a threshold, or a deviation.

2.2 What is an Event-Driven Architecture?

In an event-driven architecture, a notable thing happens inside or outside your business, which disseminates immediately to all interested parties (human or automated). The interested parties evaluate the event, and optionally take action. The event-driven action may include the invocation of a service, the triggering of a business process, and /or further information publication /syndication. Extreme Loose Coupling. By its nature, an event-driven architecture is extremely loosely coupled, and highly distributed. The creator (source) of the event only knows the event transpired. The creator has no knowledge of the event’s subsequent processing, or the interested parties. The traceability of an event through a dynamic multipath event network can be difficult. Thus, event-driven architectures are best used for asynchronous flows of work and information.

2.2.1 Event Processing Styles

There are three general styles of event processing: simple, stream, and complex. The three styles are often used together in a mature event-driven architecture.

2.2.1.1 Simple Event Processing.

In simple event processing, a notable event happens, initiating downstream action(s). Simple event processing is commonly used to drive the real-time flow of work—taking lag time and cost out of a business.

2.2.1.2 Stream Event Processing.

In stream event processing, both ordinary and notable events happen. Ordinary events (orders, RFID transmissions) are both screened for notability and streamed to information subscribers. Stream event processing is commonly used to drive the real-time flow of information in and around the enterprise––enabling in-time decision making.

2.2.1.3 Complex Event Processing.

Complex event processing (CEP) deals with evaluating a confluence of events and then taking action. The events (notable or ordinary) may cross event types and occur over a long period of time. The event correlation may be casual, temporal, or spatial. CEP requires the employment of sophisticated event interpreters, event-pattern definition and matching, and correlation techniques. CEP is commonly used to detect and respond to business anomalies, threats, and opportunities.

Lets look at types of Event driven architecture

2.2.2 Types of events exchange

Types –> WebSockets WebHooks Rest Hooks Pub-Sub Server Sent Events ClientServer
Communication overheads Low Medium Medium Low Low High
Duplex Yes Yes Yes Yes No No
Throughput High High High High High Low
Support in Browser Yes Yes No No No Yes
Caching No Yes Yes No No Yes
Scalability No Yes Yes Yes No Yes
Loosely Coupled No No No Yes No No
Com protocol TCP HTTP HTTP TCP TCP HTTP
Examples Notifications GitHub   Radio Channel    
  • In Webhooks, code can be passed as an argument to another chunk of code
  • In pub-sub, can’t effectively notify provider whether the message has been sent or not
  • Server sent events can work in low bandwidth scenarios as well.

2.2.3 Conclusion

If system is built for scalability with low overhead in a browser environment, WebSockets are a great solution. Conversely, if those same benefits are needed in a non-browser system, then WebHooks should be selected. REST Hooks are not only great for RESTful services, they are also much easier to set up than either, and thus are great in low-time high-rush situations. Pub-Sub can be great if it requires to enforce a division between client and server, and this can further be established and controlled in an even stronger way with Server Sent events.

2.2.4 References :-

2.2.4.1 Websites

2.2.4.2 Videos

  • The Many Meanings of Event-Driven Architecture - Martin Fowler

2.2.4.3 Gurus and Their Blogs

2.3 Developer Experience

We can define developer experience as

Developer experience is the sum of all interactions and events, both positive and negative, between a developer and a library, tool, or API.

2.3.1 Developer audience

Developer can be of two types

  1. Internal Developers - Working inside the organization
  2. External Developers - These are external developers which uses our exposed API’s.

2.3.1.1 Internal Developers

For so long all the attention is on UX(user experience).While developing any API or service attention is primarily on end user, But most important people in all these process remains forgotten those are developers.For any organization to be successful it’s developers needs to be productive and they will be productive if they are happy with the tools, environment and overall culture given to them.

For example, If a developer is given an laptop with only 2GB of RAM and windows 7 on it, then he/ she won’t be able to install most of application he/ she wanted to, his/ her system will get slower over time and productivity automatically will reduce.This is perfect example of how bad developer experience can cost organization.

Another example would be developer have very low end server for development while prod has some other configuration.

2.3.1.2 External Developers

Lets look developer Experience from an Open API perspective.As you write an API.It will get consumed by many people including APP developers or some other developers, so you need to write api in such a way that it can be understood by anyone.

2.3.1.2.1 What Is A Bad API Developer Experience?

Information, no matter how useful it is, won’t be consumed if the experience is not presented well, is not structured well, and is not interactive.

2.3.1.2.2 What makes great Open API

  • Making it very clear what the API does
  • Having great documentation
  • Having some portal for consumers of our API. Portal will help to serve each consumer separately and will also help in maintaining accountability of our API usage.

Moreover, An organization can run developer program which will take care of overall developer experience.

2.3.1.2.3 Creating a Developer Program

2.3.1.2.3.1 Developer portal :-

  • Key Element of developer Program
  • There shouldn’t be any sign up
  • There should be getting started guides, API reference documentation, or source code help to reduce the learning curve

2.3.1.2.3.2 Community building :-

  • Includes physical and virtual presence
  • Physical presence is more about Events,Hackethons,dev confs, trainings
  • Communications and social media

2.3.1.2.3.3 Pilot partners and case studies :-

  • Pilot partners are early adopters
  • You will get Get early feedback and helps you to build confidence

2.3.1.2.3.4 Measuring :-

  • Measure effectiveness of developer program
  • Includes Page visits, sign ups, Api traffic

Context.IO has a pretty “high touch” approach to developer experience. Example :- https://context.io/

2.3.1.3.4 How to Measure API Usability

  1. Task-Invocation Ratio: How many calls to the API does it take to accomplish each objective?
  2. Structure: What is the structure of the request and response? How deep does a developer have to go to get what they want?
  3. Navigation: How much noise is there? How difficult is it to move the data they want?
  4. Developer Stack Size: How many additional tools and libraries does a developer need to install in order to use your API?
  5. Time to First Call: How quickly can a new user make the first call to the API?
  6. Error Handling: What is the nature of the errors that are happening? How difficult are they to fix? Whose fault are they? Where are they happening?
  7. Vocabulary: What does a developer need to know in order to use your API easily?

2.3.2 References :-

2.3.2.1 Websites

2.3.2.2 Videos

  • Developers are People Too! Building a DX based API Strategy
  • Developer experience as a new differentiator

2.3.2.3 Gurus and Their Blogs

  • Guru – Ronnie Mitra Blog <!–
    • Guru - Manfred Bortenschlager Blog –>

2.4 Public Gateway

Public gateways or API gateways are becoming a must requirement because of the main reason - How do the clients of a Microservices-based application access the individual services?

Suppose in a monolithic application architecture, a mobile client want to retrieve some data. It would just hit some API URL. A load balancer routes the request to identical instance. In contrast, when using the microservice architecture, data is owned by multiple microservices, so client needs to hit multiple microservices to get required information.

Example - Client connecting to multiple services

2.4.1 Problems while connecting individual services

  • Micro services normally provide fine grained APIs which means that client need to interact with multiple services.
  • Different clients different data. (eg. Desktop, mobile)
  • Network performance is different for each client
  • Service instances and their locations changes dynamically
  • Services might use diverse set of protocols, some of which may not be web friendly.

2.4.2 Solution – Use an API gateway

A much better approach is to use API gateway. It is a server that is single entry point into the system. It encapsulates the internal system architecture and provide an API that is tailored to each client.

Example:- Client connecting to api gateway

The API gateway is responsible for request routing, composition and protocol translation. All request from clients first go through API gateway. It then routes requests to the appropriate microservice. The API Gateway will often handle a request by invoking multiple microservices and aggregating the results. It can translate between web protocols such as HTTP and Web Socket and web unfriendly protocols that are used internally.

The API gateway provides an endpoint that enables mobile client to retrieve all details with single request.

Another approach to build API gateway such that each client will have its own API gateway.

Example:- Client specific API gateway

2.4.3 What API gateway does ?

(1) Access control- only allow authenticated and authorized traffic

(2) Rate limiting - restrict how much traffic is sent to your API

(3) Analytics, metrics and logging – track how your API is used

(4) Security filtering – make sure the incoming traffic is not an attack

(5) Redirection – send traffic to a different endpoint

The API Gateway is responsible for aggregating data and acting as a simple routing layer for appropriate services.The gateway works as a set of modules and filters which treat the traffic as it flows through it at high speed and we can control their parameters.The API gateway can be seen as a single point of failure. A better approach may be to create multiple API gateways.The Netflix API is the front door to that system, supporting over 1,000 different device types and handing over 50,000 requests per second during peak hours.

2.4.3 API management platforms

(1) Kong by Mashape

(2) Azure API Management by Microsoft

(3) Cloud Endpoints by Google(not full-fledged)

(4) API Gateway by Amazon

2.4.4 Implementing an API gateway

2.4.4.1 Design issues need to consider:-

  1. Performance and scalability -

    For most applications the performance and scalability of the API Gateway is usually very important. There are a variety of different technologies that can be used to implement a scalable API Gateway. Example Node.js, which is a platform built on Chrome’s JavaScript engine.

  2. Using a Reactive Programming Model -

    Writing API code using the traditional asynchronous callback approach quickly leads you to callback hell. The code will be tangled, difficult to understand, and error prone. A much better approach is to write API Gateway code in a declarative style using a reactive approach. Example –Promises in JavaScript

  3. Service Invocation

    Microservice based application must use an inter-process communication mechanism. There are two styles of it. One is an asynchronous, messaging based mechanism. Examples - JMS or AMQP. Second one is a synchronous mechanism such as HTTP or Thrift.

  4. Service Discovery

    The API Gateway needs to know the location (IP address and port) of each microservice with which it communicates. In a traditional application, you could probably hardwire the locations, but in a modern, cloud based microservices application this is a nontrivial problem. API Gateway needs to use the system’s service discovery mechanism by querying System registry.

  5. Handling Partial Failures

    Another issue you have to address when implementing an API Gateway is the problem of partial failure. This issue arises in all distributed systems whenever one service calls another service that is either responding slowly or is unavailable. This kind of issue needs to be handled.

2.4.5 References :-

2.4.5.1 Websites

2.4.5.2 Videos

  • Microservices & API Gateways

2.4.5.3 Gurus and Their Blogs

  • Guru – Chris Richardson

  • Blog - http://www.chrisrichardson.net/

  • Guru - Ben Christensen
  • Blog - http://benjchristensen.com/

2.5 Microservices SoA Topologies

2.5.1 Topologies for Designing a Microservices Architecture

2.5.1.1 Create a Separate Data Store for Each Microservice -

Do not use the same backend data store across microservices. You want the team for each microservice to choose the database that best suits the service. Breaking apart the data can make data management more complicated, because the separate storage systems can more easily get out sync or become inconsistent. You need to add tools for master-data-management.

2.5.1.2 Keep all code in a microservice at a similar level of maturity and stability -

If you need to add or rewrite some of the code in a deployed microservice that’s working well, the best approach is usually to create a new microservice for the new or changed code, leaving the existing microservice in place. This way you can iteratively deploy and test the new code until it is bug free and maximally efficient, without risking failure.

2.5.1.3. Deploy in Containers -

Deploying microservices in containers is important because it means you need just one tool to deploy everything. As long as the microservice is in a container, the tool knows how to deploy it. It doesn’t matter what the container is.Example - Docker

2.5.1.4. Treat Servers as Stateless -

Treat servers, particularly those that run customer facing code, as interchangeable members of a group. They all perform the same functions, so you don’t need to be concerned about them individually. Your only concern is that there are enough of them to produce the amount of work you need, and you can use auto scaling to adjust the numbers up and down.

2.5.2 The Benefits of Microservices

  • Tackles the problem of complexity
  • Decomposed app into set of services
  • Enables services to be deployed independently.
  • Enables Service to be scaled independently.
  • Teams can work independently on each service.

2.5.3 The Drawbacks of Microservices

  • Distributed system sometimes arises complexity.
  • Partitioned database architecture.
  • Deploying a micro service base app is much more complex.

2.5.4 Conclusion

Building complex applications is inherently difficult. A Monolithic architecture only makes sense for simple, lightweight applications. You will end up in a world of pain if you use it for complex applications. The Microservices architecture pattern is the better choice for complex, evolving applications despite the drawbacks and implementation challenges.

2.5.5 References :-

2.5.5.1 Websites

This whitepaper shows you how innovations from Amazon Web Services (AWS) can change how you can design multi-tiered architectures for popular patterns such as microservices, mobile back ends, and public websites. Architects and developers can now use an implementation pattern that includes Amazon API Gateway and AWS Lambda to reduce the development and operations cycles required to create and operationally manage multi-tiered applications.

2.5.5.2 Videos

  • Microservices • Martin Fowler
  • Mastering Chaos - A Netflix Guide to Microservices
  • An Overview of Designing Microservices - March 2017 AWS Online Tech Talks

2.5.5.3 Gurus and Their Blogs