API Conference wrap-up, lesson 3: microservices management

As we continue with the three lessons from the API Conference in Berlin in September, we now come to the final lesson 3: microservices management.

As you may remember from lesson 1 and lesson 2, Axway’s Cedric Monier, a VP for the API Product Line, presented a fascinating seminar on “Lessons Learned and How to Succeed” on three waves of topics: SOA, API Management and Microservice Management.

What is microservices management?

According to Wikipedia, “A microservice is a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services.”

During the presentation, Cedric stated that “with a traditional SOA service, you have “logically encapsulated, monolithic deployments, large-grained (capability), logically coupled, request driven and shared data.

With microservices, you have “physically encapsulated, independently deployable, coarse-granted (domain) loosely coupled, request-driven, as well as its own data.”

When you move on to microservices, you are “physically independent, independently deployable, fine-grained (function), decoupled, event-driven and they have their own data. It’s easy to deploy and completely autonomous so they are independent.”

These days, customers are ending up somewhere in the middle; you will have smaller services that you deploy. Nothing wrong with the middle approach as it’s in transition to microservices.

Challenges

While API Management is focused at the external edge, with microservices, you will have an explosion of APIs. They are independent of each other and there are many challenges to face.

With microservices, you have challenges in terms of managing traffic, security and managing your microservices. Unfortunately, this leads to problems with security. As Cedric mentioned, “the good thing about the internal edge is you are less worried about security attacks as you are in the middle.” With microservices, the number of threats tends to explode and cause more complications.

Due to a lot of microservices and their consumers, you will run into the problem of consumption. From this point, you will need to evaluate what threats to be aware of with your microservices.

Scalability

Cedric says you “scale based on consumption, how many times per day when you have a microservices approach you want to have independence. You want to scale up and down with the right protection.” You will need to transition to a different microservices via a gateway. Although there can be hiccups, with service A to service B. With microservices, you have a network. Things can happen. “Service A can scale in the separation of service B.”

Things to solve

When you have microservices, there are a few things to keep in mind that you must address for relative communication: Self-discovery, retries, timeouts, load balancing, rate limiting, circuit breaking, security, to name a few.

Solutions

There are some solutions out there to consider. Take the open source solution, the Netflix stack, Eureka for service registry, assemble all the open source that is available to address the challenges. One problem with this is you must integrate many libraries. They create conflicts in terms of deployment.

Second approach

With a single stack approach like “Spring Boot,” it’s easier to manage the dependencies. It’s integrated. If you’re using Java, it’s probably your best option per Cedric.

Another choice is one side-car which brings little impact to your services. This gets delegated so you have a negligible impact on your microservices. Since you have many languages, you can choose the service that works best for you from Stacks to Java.

You also have great APIs, policy extensibility. This helps to remove complexity from your microservices. With this option, you can use a side-car and focus on addressing your business needs.

So how do you combine API and microservices management?

In microservices, you have a lot of APIs. Cedric stated that “what we believe at Axway is that you need a multilayer approach that you can deploy on any cloud. And you want to be able to deploy using all your capabilities.” You need to have a Service Mesh that integrates together. We also have a Policy Engine, so you can protect your APIs, as well as manage them.

You can manage the excess traffic and control around your domain. Axway puts in an API Management layer to protect and manage the traffic. So, at the high level, “it’s about protecting your service at scale. And connect it to your ecosystem.”