Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Photo by Scott Graham on Unsplash
REST-based APIs have become the main building blocks in the modern digital ecosystem. API-based integration is becoming the default model for integration within the organization, and also to expose an organization's business functionality to their partner network or even to the general public. For these APIs, data is the main constituent.
While we are talking about microservices, we talk a lot about Domain-Driven Design, Event-Driven Architecture, Core Domain, Subdomain, Bounded Context, Anti-corruption Layer, etc.
Whether you are working in a Brownfield project or a Greenfield project, if your organization wants to adopt microservices, (assuming your organization has a compelling reason for adopting microservices, as it is not a free lunch), then you need to understand the above terms in detail to properly decompose your business domain logic (Business Space) and map it with microservices architecture (Code Space), so you can gain the benefits of microservice traits.
I have heard the below questions many times
'How do I scale Microservices?'
This is the ninth article documenting what I’ve learned from a series of 13 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”). eCars allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous article, you can find it here.
Just as a quick reminder: I’ve been following this Trailhead Live video series to brush up and stay current on the latest app development trends on these platforms that are key for my career and business. I’ll be sharing each step for building the app, what I’ve learned, and my thoughts from each session. These series reviews are both for my own edification as well as for others who might benefit from this content.
Welcome fellow explorer! It seems like you are deep into microservices already. It must have taken a lot of effort to find this article!
Let’s start with a heart-felt congratulations first!
Although the question is simple, it is tough to answer, as 'Microservice' does not have any de-facto standard. As a result, many people have many perspectives on Microservices, and there are so many definitions.
The compelling definition is:
The microservice architecture pattern, which is used widely across tech companies large and small, enables businesses to distribute functionality between many small applications, instead of larger monolithic portions. Each piece has a specifically defined task, along with communications and other services, usually via a REST API channel. The benefits of utilizing a microservice architecture include, but are not limited to:
Simple development and maintenance of applications: developers and teams are able to focus on one application rather than multiple, with the benefit of faster development, and fewer hitches (such as bug and easy to miss errors) in the larger project.
For many years, monolithic applications were the standard enterprise architecture for achieving business requirements. But that changed significantly once cloud infrastructure began treating business acceleration at scale and speed. Application architectures have also transformed to fit into the cloud-native applications and the microservices, serverless, and event-driven services that are running on immutable infrastructures across hybrid and multi-cloud platforms.
According to the Cloud Native Computing Foundation (CNCF):
There are many ways to configure the cache in a microservices system. As a rule of thumb, you should use caching only in one place; for example, you should not use the cache in both the HTTP and application layers. Distributed caching both increases cloud-native application performance and minimizes the overhead of creating new microservices.
Infinispan is an open-source, in-memory data grid that can run as a distributed cache or a NoSQL datastore. You could use it as a cache, such as for session clustering, or as a data grid in front of the database. Red Hat Data Grid builds on Infinispan with additional features and support for enterprise production environments.
Migrating to a microservices from old an monolithic application is gaining traction and has become a trend. Most organizations are encouraging developers to create APIs that can help them to achieve digital transformation goals. If you have a complex system to develop but you need to deliver quickly and iteratively over a long period, then going with APIs is a good choice. Now, the question is: How do you secure these APIs? Securing APIs should start from the beginning — from design itself. Below are some patterns that can help secure your APIs.
Developers should think about writing secure code at the beginning. If we follow OWASP (Open Web Application Security Project) guidelines, tools, and training, almost 85% of code vulnerabilities can be fixed. It is very important to validate each and every input that my application receives. For example, let's say my API is accepting name as string parameter and doing some business logic. Instead of just looking for name as not null, make sure to look for a specific pattern, like that name will contain only characters or numbers. This will rule out any pattern which might use for SQL injection.
In this article, we will understand how to create Spring-based Microservices using a Use Case.
Let’s consider the use case of BookMyHotel Web Application, developed by a company known as MyInternetSolutions.
Monitoring and debugging microservices and distributed systems is not trivial. With the rise of containers and ephemeral infrastructure, it is even more critical to have all the data available for the applications. The monitoring as of today is usually done across three axes: metric monitoring, logs, and distributed tracing
Stop reverse engineering applications and start monitoring from the inside.
We launched the new checkout ecosystem, 'Erebor,' a few months ago in Hepsiburada. In this article, I will talk about what we have experienced during this microservice transformation.
“A software ecosystem is the interaction of a set of actors on top of a common technological platform that results in a number of software solutions or services.” Software Ecosystem: Understanding an Indispensable Technology and Industry by David G. Messerschmitt and Clemens Szyperski
In today’s world, business relies heavily on digital infrastructure to maintain both the economic and social fabric of our society. This comes with greater responsibility for enterprise IT teams to ensure the security of data at rest and in transit. Enterprise businesses follow different security compliance protocols like GDPR to ensure maximum security for the data and infrastructure.
When it comes to security in the integration world, the security of data in transit is vital. In some business domains such as banks, medical & pharma, defense, etc. where sensitive data flows across different systems, the criticality is multifold. Transport-level security and message-level security are the most common security levels enforced when services are integrated between client and server or between servers. Multiple intermediary systems could exist between two end points when integrated. In such cases, message-level encryption (MLE) ensures that the content is encrypted during the intermediate hops where the traffic itself might be un-encrypted before it reaches the target system.
An integral part of Zato, its scalable, service-oriented scheduler makes it is possible to execute high-level API integration processes as background tasks. The scheduler runs periodic jobs, which, in turn, trigger services, and services are what are used to integrate systems.
In this article, we will check how to use the scheduler with three kinds of jobs, one-time, interval-based, and Cron-style ones.
This is the second part of our four-part series that will take a deep dive through a real-time use case of migrating a developed service on Mulesoft. The Mulesoft service described in this article will cover some of the patterns mentioned in our earlier article. We will learn how to migrate this service into Kumologica without negotiating the pattern.
For those who are new to Kumologica, I would recommend going through our articles and youtube videos to get an insight. Kumologica is one of the early players in this space, which brings the benefits of the low-code integration capability of traditional integration like Mulesoft to Serverless's new world. It provides a drag and drops visual designer and low code approach to ensure the greatest speed and flexibility to support a wide range of integrations compatible with most platforms and cloud providers.
This is the first part of our four-part series we are publishing which takes you through the steps for migrating your application from Mulesoft to a serverless integration using Kumologica. Mulesoft follows the EAI (Enterprise application Integration) patterns based on which the Mulesoft processors and connectors are aligned. We will discuss some of these patterns as we move through the series.
Kumologica is one of the early players in this space which brings the benefits of the low-code integration capability of traditional integration like Mulesoft to the new world of Serverless. It provides a drag and drop visual designer and low code approach to ensure the greatest speed and flexibility to support a wide range of integrations compatible with most of the platforms and cloud providers.
SOAP (Simple Object Access Protocol) is a standards-based web services access protocol that has been ruling the integration world for a long time. SOAP-based web services were the de facto standard for SOA (Service Oriented Architecture). As the architecture moved from SOA to Microservices the enterprise started embracing the new philosophy from Roy Fielding, which we call today REST (Representational State Transfer). REST is an architectural style that relies on HTTP protocol without any support of higher level protocol like SOAP.
Below are major reasons for the popularity and motivation for moving from SOAP to REST: