What is Helm, and what is a Helm Chart? Helm is the package manager for Kubernetes — in other words, it is used to help you manage Kubernetes applications. Helm Charts allow you to define, install and configure your Kubernetes application. Kubernetes is an open source system, which allows you to automate, deploy, scale and otherwise manage applications. The charts are easy to create, share and publish, which makes them so popular. A chart is a collection of files that describe a set of Kubernetes resources. One chart can be used to deploy something very simple or a full web application stack with HTTP servers and databases.

Have I confused you yet? Have you used Yellowdog Updater, Modified (YUM) before? Helm is analogous to YUM. Have you used Red Hat Package Manager (RPM) files before? Helm Charts are packages, which are analogous to RPMs. The home for the Helm Charts are the Kubernetes manifests, which provide the configuration parameters allowing users to customize their deployment. The latest version of Helm is actually maintained by the Cloud Native Computing Foundation, in collaboration with Microsoft, Google, Bitnami and the greater community.

The post What is a Helm Chart and how can it improve microservices? appeared first on Artificial Intelligence.

Monitoring gives us observability in our system and helps us to discover, understand, and address issues to minimize their impact on the business. It’s clear then, why you should aim for the best solutions out there; especially when you build a microservices architecture that has brought up new challenges in regards to observability.

The future of microservices monitoring depends on what kind of solutions become standardized in the industry and what new features will we see in the future that will make your applications much better. In this article I theorize what are these new monitoring features and what can we expect in 2018.

Microservices Monitoring and Instrumentation

To collect and analyze monitoring data, first, you need to extract metrics from your system – like the Memory usage of a particular application instance. The type of monitoring that provides details about the internal state of your application is called white-box monitoring, and the metrics extraction process is called instrumentation.

Current APM (Application Performance Monitoring) solutions on the market like NewRelic and Dynatrace rely heavily on different levels of instrumentations, this is why you have to install vendor specific agents to collect metrics into these products.

Agents can instrument your application at various places. They can extract low-level language specific metrics like Garbage Collector behavior or library specific things like RPC and database latencies as well.

Keep in mind that instrumentations can be very specific and usually need expertise and development time. As instrumentations are part of the running code, a bad instrumentation can introduce bugs into your system or generate an unreasonable performance overhead.

Instrumenting your system can also produce extra lines of code and bloat your application’s codebase.

The Agent World of APM Vendors

We discussed earlier that current APM solutions provide agents to instrument our application and collect metrics. Creating and maintaining these agents need a lot of effort from the APM vendors side as they have to support multiple versions of languages and libraries that their customers use.

They need to continuously run tests against these different versions and benchmark their performance overhead to ensure that they won’t introduce any bug into the instrumented application.

If you check out collector agents from multiple APM vendors, you will realize that they are very similar from an implementation point of view. These companies put a tremendous amount of work to create the best agent for their customers while they reimplement the same thing and maintain their agent separately.

Having vendor specific agents can also lead to a situation when developers start to use multiple monitoring solutions and agents together as they miss some features from their current APM solution. Multiple agents usually mean multiple instrumentations on the same code piece, which can lead to an unnecessary performance overhead, false metrics or even bugs.

I think that the trend of using vendor-specific agents will change in the future and APM providers will join their efforts to create an open standard for instrumenting code. The future could lead to an era where agents are vendor-neutral, and all values will come from different backend and UI features.

Containers and Microservices Change the Game

Latest technology and architecture trends like containerization and microservices changed the way we write and run our applications.

The new era of these highly dynamic distributed systems brought new challenges to the art of observability. To monitor and debug these architectures, we need a new set of tools that are capable of storing and querying a large amount of multidimensional metrics series from different services and are also able to discover issues in microservices.

One of the new debugging methodologies is distributed tracing. It propagates transactions from distributed services and gains information from cross-process communication. To be able to track operations between applications, our instrumentation needs to share contextual information (like transaction ID’s) between processes in a standardized way. For example, when we create an RPC request to another service, it should share certain tracing information in meta headers to enable reverse engineering the transaction later.

With this kind of context sharing on the instrumentation level we can follow a request across the whole system; from the client through the underlying backend systems, network components, and databases. This kind of observability makes debugging in distributed systems, such as microservices, much easier. However, the popularity of microservices architectures is growing rapidly, distributed tracing is still in its early ages. Enterprise companies just started to evaluate the technology and discover its capabilities. We can expect an increasing amount of distributed tracing solutions in 2018 by early adopter companies.

New Instrumentation Standards: OpenTracing

In the previous sections, we discussed that an optimal instrumentation should have a vendor-neutral standardized interface with cross-process context sharing capabilities and only a minimal performance impact.

This is the challenge that OpenTracing wants to address with providing a standard, vendor-neutral interface for distributed tracing instrumentations. OpenTracing provides a standard API to instrument your code and connects it with different tracing backends. It also makes it possible to instrument your code once and change the Tracing backend without trouble anytime.

Check out the following code snippet to understand OpenTracing’s approach to standardized instrumentation:

const server = http.createServer((req, res) => {
  const requestSpan = tracer.startSpan('http_request', {
    childOf: tracer.extract(FORMAT_HTTP_HEADERS, req.headers)
  })
  const headers = {}

  metricsTracer.inject(requestSpan, FORMAT_HTTP_HEADERS, headers)

  requestSpan.setTag(Tags.HTTP_URL, req.url)
  requestSpan.setTag(Tags.HTTP_METHOD, req.method || 'GET')
  requestSpan.setTag(Tags.HTTP_STATUS_CODE, 200)
  requestSpan.setTag(Tags.SPAN_KIND_RPC_CLIENT, true)

  const childOperationSpan = tracer.startSpan('my_operation', {
    childOf: requestSpan
  })
  childOperationSpan.finish()

  res.writeHead(200, headers)
  res.end('Ok')
  requestSpan.finish()
})

Node.js OpenTracing Instrumentation

In certain languages, such as Node.js, it’s also possible to do the instrumentation automatically via the OpenTracing API. In this case, you only need to specify which backends you want to use to collect metrics. The helper library will instrument your code and call the standard Tracer API for the necessary events, for example when an HTTP request or database call happens.

The following code demonstrates how you can use multiple OpenTracing compatible Tracer backends with automatic instrumentation:

const Instrument = require('@risingstack/opentracing-auto')
const Tracer1 = require('tracer-1')
const Tracer1 = require('tracer-2')
const tracer1 = new Tracer1()
const tracer2 = new Tracer2()

const instrument = new Instrument({
  tracers: [tracer1, tracer2]
})

The future of standardized instrumentation also means that maintainers of open-source libraries and service providers can ship their solutions with built-in instrumentation. As they know the best how their libraries work and they have ownership of their internal behavior, this would be the optimal and the most risk-free solution.

I expect more and more standardized solutions for instrumentation in the future, and I hope one day all of the APM providers will work together to provide the best vendor-neutral agent. In this scenario, they will compete in who can provide the most insight and value on their backend and UI.

The One Microservices Instrumentation

OpenTracing is born to provide a vendor-neutral standard instrumentation for distributed tracing solutions, but it doesn’t mean that we cannot extract other kinds of information, like time-series metrics or error logs from it.

For example, by writing an OpenTracing compatible Tracer that calculates operation durations, we can measure request latency, throughput, and dependencies that can be consumed by monitoring solutions, like Prometheus. By collecting spans (events) with error flags to Elasticsearch or a similar storage, we can have an error tracker with only one instrumentation and multiple Tracer backends. In this way, we don’t have to double instrument our code per use-cases and deal with the performance overhead.

As OpenTracing also provides context about cross-process communications, we can use it to measure distributed operations in our system. For example, we can detect the throughput between two services, and we can also differentiate the metrics of traffic that comes from various sources.

Check out the following request throughout the metrics exported by OpenTracing to Prometheus. It contains the initiator parent_service label which we could determinate by the cross-process context sharing. The unknown value means that the source is not instrumented (in our case it’s the Prometheus scraper job that calls our service GET /metrics endpoint every 5 seconds):

Element
Value
{parent_service="my-server-1",service="my-server-3"}
10296
{parent_service="my-server-1",service="my-server-2"}
11166
{parent_service="unknown",service="my-server-1"}
10937
{parent_service="unknown",service="my-server-2"}
12
{parent_service="unknown",service="my-server-3"}

With the special OpenTracing Metrics Tracer we extract the data about the initiator of a specific RPC call. Then, we can reverse engineer the whole infrastructure topology based on this information and visualize the dependencies between services. From these metrics, we can also gain information about throughput and latencies between applications and databases in our microservices architecture.

The post The Future of Microservices Monitoring & Instrumentation appeared first on Artificial Intelligence.

A service registry sits between a client and server in a network and controls access between both of them. It is a critical part of the application stack and has a big impact on the end-user experience. With the growing use of microservices, the role of a service registry has become even more important as the number of services that talk to each other has grown exponentially.

Service registries need to be fine-tuned and rearchitected to function seamlessly in a microservices world. More importantly, they need to be governed differently from older models. Let’s look at how we can better govern service registries and why a modern platform like Kubernetes does it the right way.

The post Does Kubernetes service governance work for microservices? appeared first on Artificial Intelligence.

Enterprises are increasingly turning to a microservice architecture for new applications to achieve greater agility and scalability, and the software industry is supporting them with development frameworks and tools for creating microservices. Yet, these don’t operate in a vacuum and often require an effective approach to integration.

The challenge is that building integration logic from scratch at the microservices layer is essentially reinventing the wheel while adding a traditional integration layer defeats some key objectives of a fully distributed microservice model. What’s needed instead are new solutions designed specifically to handle integration microservices.

Working with various enterprises, we’ve seen the common challenges they face when integrating microservices. First, let’s understand why traditional integration approaches fall short and then explore the need for a new approach centered around integration microservices.

A typical organization has backend systems and a centralized services bus layer, usually via an enterprise service bus (ESB), which channels all integration logic and is governed by a centralized team. Because it enables a standard way to publish any integration logic and a single place to update changes to the backend systems, the enterprise can minimize complexity and optimize performance. This works well for service-oriented architectures, but a traditional ESB has a comparatively large footprint and takes too long to start up to support the leaner, distributed nature of microservices.

Recognizing that ESBs are not a fit for microservices, some developers are either building integration into the microservices or relying on APIs to integrate them. Yet, these approaches fail to provide some important reusable constructs offered by ESBs, such as pre-built connectors, integration templates and patterns, mediation, and transformation logic. To be clear, APIs are central to a microservice architecture, but they are not a workaround for integration requirements.

Integration Microservices refines your approach to integration

A better alternative is an integration microservice approach where conventional microservices and integration microservices interact with each other. This enables developers to utilize integration microservices for mediation, transformations and other integration functions for services or to compose multiple services into a single service.

Essentially, an integration microservice helps to leverage the essentials of microservices and add these to the integration layer. These integration microservices can be considered as a mini-services layer for composite services linking or chaining multiple fine-grained backend systems, as well as transforming and/or connecting to cloud systems, as shown in Figure 1.

Figure 1: A reference model for integration microservices

Moreover, an integration microservice approach gives development teams greater flexibility and end-to-end responsibility of their code. This means the same (small) team can be tasked with the creation of core services and composite services, database handling, integration logic, cloud connectivity, protocol transformation, user experience (UX) development, etc.

The architecture described here is best supported by a programming language that enables developers to build lean, microservice-style integrations while still using existing integration concepts—such as connectors, service chaining, and routing—when writing a new service.

As a programming language versus a highly specialized configuration language, it provides the added benefit of being intuitive for developers while naturally being compatible with development tools.

Ideally, to cater to today’s demand for citizen and ad-hoc integrators, it should also provide a visually intuitive interface, possibly replacing traditional data flow-driven approaches with a more visual tool that ensures parity between the visual model and the programming model. A much more understandable approach, such as sequence diagrams, would be applicable here.

For instance, a microservice that exposes customer information might need to connect to Salesforce, meaning the developer must build a connector or call a set of APIs. In another scenario, there might be a difference between the incoming message XML format and what the backend system expects. For such integration scenarios, it may be possible to build reusable integration logic into each service. However, only through a separate integration microservice layer can developers ensure scalability—not only in terms of time, effort and cost, but also in terms of re-work and maintaining the dependencies of libraries.

As leaner, agile, DevOps-based, distributed, and microservice-style development becomes the preferred go-to technology model, developers have struggled to find the right approach to integration. An integration microservice approach promises to provide the missing link with its ability to tackle integration challenges in a highly scalable manner while providing the agility to meet evolving requirements.

The post Microservices demand a micro approach to integration appeared first on Artificial Intelligence.

A Microservices architecture makes it possible to isolate failuresthrough well-defined service boundaries. But like in every distributed system, there is a higher chance for network, hardware or application level issues. As a consequence of service dependencies, any component can be temporarily unavailable for their consumers. To minimize the impact of partial outages we need to build fault tolerant services that can gracefully respond to certain types of outages.

This article introduces the most common techniques and architecture patterns to build and operate a highly available microservices system based on RisingStack’s Node.js Consulting & Development experience.

If you are not familiar with the patterns in this article, it doesn’t necessarily mean that you do something wrong. Building a reliable system always comes with an extra cost.

The Risk of the Microservices Architecture

The microservices architecture moves application logic to services and uses a network layer to communicate between them. Communicating over a network instead of in-memory calls brings extra latency and complexity to the system which requires cooperation between multiple physical and logical components. The increased complexity of the distributed system leads to a higher chance of particular network failures.

One of the biggest advantage of a microservices architecture over a monolithic one is that teams can independently design, develop and deploy their services. They have full ownership over their service’s lifecycle. It also means that teams have no control over their service dependencies as it’s more likely managed by a different team. With a microservices architecture, we need to keep in mind that provider services can be temporarily unavailable by broken releases, configurations, and other changes as they are controlled by someone else and components move independently from each other.

Graceful Service Degradation

One of the best advantages of a microservices architecture is that you can isolate failures and achieve graceful service degradation as components fail separately. For example, during an outage customers in a photo sharing application maybe cannot upload a new picture, but they can still browse, edit and share their existing photos.

Microservices fail separately (in theory)

In most of the cases, it’s hard to implement this kind of graceful service degradation as applications in a distributed system depend on each other, and you need to apply several failover logics (some of them will be covered by this article later) to prepare for temporary glitches and outages.

Services depend on each other and fail together without failover logics.

Change management

Google’s site reliability team has found that roughly 70% of the outages are caused by changes in a live system. When you change something in your service – you deploy a new version of your code or change some configuration – there is always a chance for failure or the introduction of a new bug.

In a microservices architecture, services depend on each other. This is why you should minimize failures and limit their negative effect. To deal with issues from changes, you can implement change management strategies and automatic rollouts.

For example, when you deploy new code, or you change some configuration, you should apply these changes to a subset of your instances gradually, monitor them and even automatically revert the deployment if you see that it has a negative effect on your key metrics.

Change Management – Rolling Deployment

Another solution could be that you run two production environments. You always deploy to only one of them, and you only point your load balancer to the new one after you verified that the new version works as it is expected. This is called blue-green, or red-black deployment.

Reverting code is not a bad thing. You shouldn’t leave broken code in production and then think about what went wrong. Always revert your changes when it’s necessary. The sooner the better.

Health-check and Load Balancing

Instances continuously start, restart and stop because of failures, deployments or autoscaling. It makes them temporarily or permanently unavailable. To avoid issues, your load balancer should skip unhealthy instances from the routing as they cannot serve your customers’ or sub-systems’ need.

Application instance health can be determined via external observation. You can do it with repeatedly calling a GET /healthendpoint or via self-reporting. Modern service discovery solutions continuously collect health information from instances and configure the load-balancer to route traffic only to healthy components.

Self-healing

Self-healing can help to recover an application. We can talk about self-healing when an application can do the necessary steps to recover from a broken state. In most of the cases, it is implemented by an external system that watches the instances health and restarts them when they are in a broken state for a longer period. Self-healing can be very useful in most of the cases, however, in certain situations it can cause trouble by continuously restarting the application. This might happen when your application cannot give positive health status because it is overloaded or its database connection timeouts.

Implementing an advanced self-healing solution which is prepared for a delicate situation – like a lost database connection – can be tricky. In this case, you need to add extra logic to your application to handle edge cases and let the external system know that the instance is not needed to restart immediately.

Failover Caching

Services usually fail because of network issues and changes in our system. However, most of these outages are temporary thanks to self-healing and advanced load-balancing we should find a solution to make our service work during these glitches. This is where failover caching can help and provide the necessary data to our application.

Failover caches usually use two different expiration dates; a shorter that tells how long you can use the cache in a normal situation, and a longer one that says how long can you use the cached data during failure.

Failover Caching

It’s important to mention that you can only use failover caching when it serves the outdated data better than nothing.

To set cache and failover cache, you can use standard response headers in HTTP.

For example, with the max-age header you can specify the maximum amount of time a resource will be considered fresh. With the stale-if-error header, you can determine how long should the resource be served from a cache in the case of a failure.

Modern CDNs and load balancers provide various caching and failover behaviors, but you can also create a shared library for your company that contains standard reliability solutions.

Retry Logic

There are certain situations when we cannot cache our data or we want to make changes to it, but our operations eventually fail. In these cases, we can retry our action as we can expect that the resource will recover after some time or our load-balancer sends our request to a healthy instance.

You should be careful with adding retry logic to your applications and clients, as a larger amount of retries can make things even worse or even prevent the application from recovering.

In distributed system, a microservices system retry can trigger multiple other requests or retries and start a cascading effect. To minimize the impact of retries, you should limit the number of them and use an exponential backoff algorithm to continually increase the delay between retries until you reach the maximum limit.

As a retry is initiated by the client (browser, other microservices, etc.)and the client doesn’t know that the operation failed before or after handling the request, you should prepare your application to handle idempotency. For example, when you retry a purchase operation, you shouldn’t double charge the customer. Using a unique idempotency-key for each of your transactions can help to handle retries.

Rate Limiters and Load Shedders

Rate limiting is the technique of defining how many requests can be received or processed by a particular customer or application during a timeframe. With rate limiting, for example, you can filter out customers and microservices who are responsible for traffic peaks, or you can ensure that your application doesn’t overload until autoscaling can’t come to rescue.

You can also hold back lower-priority traffic to give enough resources to critical transactions.

A rate limiter can hold back traffic peaks

A different type of rate limiter is called the concurrent request limiter. It can be useful when you have expensive endpoints that shouldn’t be called more than a specified times, while you still want to serve traffic.

A fleet usage load shedder can ensure that there are always enough resources available to serve critical transactions. It keeps some resources for high priority requests and doesn’t allow for low priority transactions to use all of them. A load shedder makes its decisions based on the whole state of the system, rather than based on a single user’s request bucket size. Load shedders help your system to recover, since they keep the core functionalities working while you have an ongoing incident.

To read more about rate limiters and load shredders, I recommend checking out Stripe’s article.

Fail Fast and Independently

In a microservices architecture we want to prepare our services to fail fast and separately. To isolate issues on service level, we can use the bulkhead pattern. You can read more about bulkheads later in this blog post.

We also want our components to fail fast as we don’t want to wait for broken instances until they timeout. Nothing is more disappointing than a hanging request and an unresponsive UI. It’s not just wasting resources but also screwing up the user experience. Our services are calling each other in a chain, so we should pay an extra attention to prevent hanging operations before these delays sum up.

The first idea that would come to your mind would be applying fine grade timeouts for each service calls. The problem with this approach is that you cannot really know what’s a good timeout value as there are certain situations when network glitches and other issues happen that only affect one-two operations. In this case, you probably don’t want to reject those requests if there’s only a few of them timeouts.

We can say that achieving the fail fast paradigm in microservices by using timeouts is an anti-pattern and you should avoid it. Instead of timeouts, you can apply the circuit-breaker pattern that depends on the success / fail statistics of operations.

Bulkheads

Bulkhead is used in the industry to partition a ship into sections, so that sections can be sealed off if there is a hull breach.

The concept of bulkheads can be applied in software development to segregate resources.

By applying the bulkheads pattern, we can protect limited resources from being exhausted. For example, we can use two connection pools instead of a shared on if we have two kinds of operations that communicate with the same database instance where we have limited number of connections. As a result of this client – resource separation, the operation that timeouts or overuses the pool won’t bring all of the other operations down.

One of the main reasons why Titanic sunk was that its bulkheads had a design failure, and the water could pour over the top of the bulkheads via the deck above and flood the entire hull.

Bulkheads in Titanic (they didn’t work)

Circuit Breakers

To limit the duration of operations, we can use timeouts. Timeouts can prevent hanging operations and keep the system responsive. However, using static, fine tuned timeouts in microservices communication is an anti-pattern as we’re in a highly dynamic environment where it’s almost impossible to come up with the right timing limitations that work well in every case.

Instead of using small and transaction-specific static timeouts, we can use circuit breakers to deal with errors. Circuit breakers are named after the real world electronic component because their behavior is identical. You can protect resources and help them to recover with circuit breakers. They can be very useful in a distributed system where a repetitive failure can lead to a snowball effect and bring the whole system down.

A circuit breaker opens when a particular type of error occurs multiple times in a short period. An open circuit breaker prevents further requests to be made – like the real one prevents electrons from flowing. Circuit breakers usually close after a certain amount of time, giving enough space for underlying services to recover.

Keep in mind that not all errors should trigger a circuit breaker. For example, you probably want to skip client side issues like requests with 4xx response codes, but include 5xx server-side failures. Some circuit breakers can have a half-open state as well. In this state, the service sends the first request to check system availability, while letting the other requests to fail. If this first request succeeds, it restores the circuit breaker to a closed state and lets the traffic flow. Otherwise, it keeps it open.

Circuit Breaker

Testing for Failures

You should continually test your system against common issues to make sure that your services can survive various failures. You should test for failures frequently to keep your team prepared for incidents.

For testing, you can use an external service that identifies groups of instances and randomly terminates one of the instances in this group. With this, you can prepare for a single instance failure, but you can even shut down entire regions to simulate a cloud provider outage.

One of the most popular testing solutions is the ChaosMonkeyresiliency tool by Netflix.

The post Designing a Microservices Architecture for Failure appeared first on Artificial Intelligence.

“Microservices Architecture” is now a popular concept in programming. In order to keep up-to-date as a software developer, I’ve been trying to get a good understanding of this architecture. Specifically, I’ve been looking at a better way to implement microservices architecture in Java using Spring.

Some background: my company, although great, had a woefully out of date tech stack. Basically, we weren’t using Java 8 or microservices yet. So I had to look outside of the company if I wanted to know more about either of those things. The easiest way to learn is by just doing it, so I decided to create a To Do system anddocument my experience for future reference.

Overview

My goal for this article is to have a source code walkthrough for different microservices. I’m not planning to go deep in the concepts and tools; there are a lot of posts about those out there. My intention here is to present an application example containing the patterns, tools, technologies used to develop microservices.

Since this is a reference application, I have intentionally made it as simple as possible so the source code is easy to understand. You should follow along at home and be able to run this application on your own computer as a reference.

In this article, we are going to work with a “To Do” application which will be composed of 8 applications:

• Reminder
• User
• Service discovery server
• Mailer
• OAuth Server
• System integration test
• API Gateway
• Web application client

This article will provide an overview of the whole project. Later, I will explain more deeply about what and how we are using the components in each microservice.

How our system will work with Microservices

In the image above, you can see how our system interacts along with all microservices. The user will access a Web Application written using Angular 2. It will then connect to an OAuth Authorization Server, which will be a central point of where users and authorities can be assigned. This server will return a JSON Web Token containing info about the client with its authorities and the grated scope. After the user is authenticated and has a token, the Web Application will be able to talk to the API gateway. It will take the JWT, verify if it’s coming from the Authorization Server, and then make calls to the microservices and build the response.

The OAuth server uses the User service to get the user’s authentication details. Also, the API gateway uses the OAuth server to get the user’s information.

The Remainder Service is where are placed the ToDo functionalities, The ToDo service has a scheduled job to check for reminders and notify the user by email, the emails are sent by the Mailer Service which is triggered from Reminder service by event using Kafka.

The System Integration Test is a Java application responsible for reaching the Reminder service’s endpoints.

Connecting Microservices

In Microservice architecture, we have to deal with many microservices running in different IPs and ports. Therefore, we need to find a way of managing each address without hard coding.

This is where Netflix Eureka comes to the rescue. It is a client-side service discovery that allows services to find and communicate with each other automatically. We are using Spring Cloud Eureka in our system; you should take a look at how it works so you can understand how our REST services are communicating between different microservices. Once Eureka cares about where the services are running, we can add instances and apply load balancing to distribute the incoming application traffic between our microservice.

In our system, we are using Netflix Ribbon as a client-side load balancer. That enables us to achieve fault tolerance and increase the reliability and availability through redundancy. We are using Netflix Foreign for writing declarative REST client, and integrating Ribbon and Eureka to provide a load balance HTTP client.

Our system does have some dependencies. We are trying to isolate our application from dependency failure using Netflix Hystrix Circuit Breaker. It helps stop cascading failures and allows us to fail fast and rapid recovery, or add fallbacks. Hystrix maintains a thread-pool for each dependency; it rejects requests instead of queuing them if the thread-pool becomes exhausted. It also provides circuit-breaker functionality that can stop all requests to a dependency. You can also implement fallback logic when a request is failed, rejected, or timed-out.

Authentication

Security is something very important when developing any kind of system. Microservices architecture is no different. “How can I maintain security in my microservices?” comes up immediately, and the first answer is OAuth2. OAuth2 is definitely a good solution: it is a well-known authorization technology that is widely used for Google, Facebook, and Github.

Anyways, it’s impossible to talk about security without mentioning Spring Security. I use it alongside OAuth2 in this project. Spring Security and OAuth2 are obvious choices when talking about secure distributed system.

However, we are adding one more element to our security concern: JSON Web Token (JWT). If we were only using OAuth, we would need to have an OAuth Authorization Server to authenticate the user, generate the token as well as act as an endpoint for the Resource servers to ask if the token is valid and which permission does it grant. This requires twice more requests to the Authorization Server than we really need. JWT provides a simple way of transmitting the permissions and user data in the access token. Once all data is already in the token string, the resource servers don’t need to ask for token checks. All the information is serialized into JSON first, encoded with base64 and finally signed with a private RSA key. It is assumed that all resource servers will have a public key to check if the token was signed for the proper private key and deserialize the token to have the information.

You can have a look at the OAuth2 Authorization Server(OAuth-server) and the Resource Server(API Gateway) implementations to see the code looks like. The implementation was done following mainly this blog post.

REST

In our system, we have two interaction styles: synchronous and asynchronous. For the async style, we are using distributed events with Kafka, following the model publish/subscribe. For synch, we have REST style supporting JSON and XML.

There are four levels of maturity of RESTful, starting at level 0, as described for Martin Fowler here. Our microservices is in the level 2, because I decided not implement the Hypermedia Controls using the HATEOAS design pattern for the simplicity.

Because we are using Spring Cloud, we have to out-of-box some scalability patterns, which are placed in our HTTP connections that deserve a mention: Circuit breaker, Bulkheads, Load Balancing, Connection pooling, timeouts, and retry.

Distributed Event

As mentioned above, our communication between the Reminder service and Mailer service is done asynchronously using Kafka to distribute our events across the others Microservices. In the Reminder service, we have a scheduled task to check for reminders time and publish the event RemainderFound. There will be a subscribed event in the Mailer service which will start the process of sending an email to the user. I invite you to have a look at how we are doing this integration and how I wrote the serialization/ deserialization of the data sent to Kafka in the Kafka event Module.

Event sourcing and CQRS

Monolithic applications typically have a single relational database. We can use ACID transactions. As a result, our application can simply begin a transaction, change multiple rows, and commit the transaction if everything go right or rollback if something goes wrong. Unfortunately, to deal with data access in the microservice architecture is much more complex. This is due to the fact that the data is distributed in different databases. Implementing business transactions across multiple services is a big challenge.

SEE MORE: From the Monolith to Microservices

In our “ToDo” project, we are using events to deal with business transaction that spans multiple services. You can look at the implementation of Event Sourcing with CQRS applied in the Mailer service. You can see how to separate Reads and Writes that enable us to scale each part easily. We are using a relational database as an event store and then distributing the events using Kafka. We will need to make these two actions Atomic and avoid storing the event, that way it won’t publish an eventual JVM crash. I’m not using Kafka as the event store because is simpler to construct the aggregates from a relational database. We are trying to make things easy here!

Next step

As you can notice, we already have a lot of things in this project and there are still many challenges that are not addressed here yet. However, this is a project in development and we are planning adding more things into it, such as Spring cloud config, Containers with Docker, continuous integration with Jenkins, Distributed trace with Spring Sleuth, Logging management with ELK and more. So keep tuned on our Github repository to see more fun things.

The post An introduction to hands-on microservices with Java appeared first on Artificial Intelligence.