Leading organizations understand the benefits they can gain by migrating existing apps to a microservices architecture and adopting the approach for new builds. However, there are inherent challenges application designers, architects and developers face around scalability, performance and deployment.

Use these 10 key microservices design principles as guidelines to build applications that meet expectations and avoid short- and long-term lifecycle issues. They range from conceptual, such as how to define the scope of a service and maintain data autonomy, to practical, such as what patterns to use to maximize network traffic performance.

1. Ensure high cohesion and low coupling

Cohesion and coupling are two terms often used interchangeably when describing a microservices architecture. The former relates to the degree of intradependence that exists between the modules of an application, and the latter is used for the degree of interdependencies.

You should design microservices so that cohesion is high and coupling is low. This plan creates microservices that are adaptable to changes, scalable and can be extended over time.

The higher the cohesion, the better, because the modules work together. If cohesion is low, the application would send too many communications back and forth between the services, causing degraded performance and scalability.

Two components are loosely coupled when they are not interdependent, i.e., if they can function without the other and if any change in one component wouldn’t break the functionality of the other. Loosely coupled components in an application should be easy to test because the component is isolatable.

2. Define the scope properly

You should define the functionality of a microservice, describing what it is intended to do. The scope of a microservice corresponds to the requirement of an independent business module. It’s important to set a proper scope for each microservice in order to rationalize its size and define its boundaries.

3. Adhere to the Single Responsibility Principle

The Single Responsibility Principle states that a class should never have more than one reason for change. This principle is essential to designing a microservices-based application, because there should not be multiple responsibilities in a single microservice.

4. Design for failure

One of the objectives of microservice architecture is to create fault-tolerant and resilient software systems. Failure or performance issues in one service should not affect other services. A memory leak, database connectivity problems or other issues in one microservice should not bring the entire application down.

Since the services in a microservices-based application are autonomous and independent, they can take advantage of the circuit breaker pattern, which is a means to cut off communication with one or more services that are down or experiencing errors.

5. Build around business capabilities

Each microservice should be designed to solve a business problem. The developer can use the appropriate technology stack for each business problem in each microservice. Unlike a monolithic application, you are not constrained to use a single best-fit homogenous technology stack for the whole architecture. This microservices design principle means developers should choose what’s best and readily available for use in every component of the application.

6. Decentralize data

Unlike in monolithic applications, microservices each maintain their own copy of the data. In other words, each microservice has its own database. You should not set up multiple services to access or share the same database, since it defeats the purpose of autonomous microservice operation.

Data pertaining to a specific microservice is private to that service. Use APIs to let other services access a microservice’s owned data. This design principle enforces centralized access control and enables the developers to implement audit logging and caching seamlessly. Aim for one or two database tables per service.

7. Gear up process automation

A microservices design can deploy in several units, which the application team must manage. Automate the deployment process for microservices-based components via smart iterative release tooling, such as a CI/CD pipeline, potentially coupled with a DevOps culture.

8. Enable interservice communication

When you migrate an existing monolithic application to microservices, you must break apart many interrelated components; these services need a way to communicate. Microservices applications also enable diverse programming languages and approaches, as explained in the fifth microservices design principle, so an application might have services built with different technologies communicating with each other. APIs make it all work.

When you set up microservices APIs, abstract the implementation details of how a service works and only expose API methods to enable external access to the service. In this setup, a microservice can scale independently.

9. Monitor constantly

Microservices in production are distributed and interrelated. It is daunting to manually discover and identify errors. Instead, use an automated monitoring system that can track performance constantly. As part of the microservices design and deployment process, select a tool or set of tools that captures and analyzes data on services’ performance, and generates useful metrics.

10. Manage traffic

Traffic to microservices in an application differs from one to the next. One service might have huge traffic while another is low-demand on the network. In each kind of traffic scenario, performance is an important factor. Take advantage of autoscaling and circuit breaker patterns to maximize performance.

The post Follow these 10 fundamental microservices design principles appeared first on Artificial Intelligence.

Akshay Aggarwal: From going from a … monolithic design paradigm to a more distributed microservices design paradigm, the transition that we are seeing is driven by business efficiencies, economies of scale, as well as trying to make things simpler by reusing functionality across different applications. What that does to security is it simplifies certain aspects, but it makes other aspectsextremely challenging.

In the monolith world, we understood the software development process well and were able to introduce adequate controls in it over a period of time. But in the microservices world, because of the distributed nature, a few fundamental things have changed.

Can you talk about some of those changes?

Aggarwal: First, application endpoints have just proliferated, so you need to secure each of those independently. And there are two other aspects that are very interesting from the monolith world to the microservices world. One is the question of identity. In the monolith world, it’s easier to manage identity and access controls. You could trust information that was going through, or a token could persist and that made it simpler for some of the functionality. In the microservices world, it’s very, very difficult to understand and establish identity. We actually see many, many firms doing this wrong.

And the second big thing that’s changed from the monolith to the microservices world has been just the speed of deployment and rolling out functionality. You’re building smaller microservices; therefore, people are responsible for … a smaller portion of functionality. We’re seeing rapid churns and deployments of new code, and that is upending the traditional approach to security for a lot of firms.

What are the major areas where organizations are making mistakes implementing security in microservices?

Aggarwal: The microservices world has made things very complex for security individuals in organizations. But it’s also made it very difficult for QA testing and DevOps [teams] because it has taken some of the complexity and pushed it down to a DevOps space that didn’t exist before. So to me, when people talked about security from an API or a microservices perspective, very often, what they’re focusing on is the security of the container or the configuration management tool. So the guys are talking about something about Chef’s container configuration management tool or Tenable’s patch management tool for those containers as well.

All of that is great. But what they’re not focusing on is the fact that the way the software is being developed itself is completely different. So, let me give you a few examples of how software development and QA processes haven’t caught up to deal with the microservices world. If you have two individual components that exist, do they share the same namespace? And if they share different namespaces, do the involved identities still have common authentication credentials? That would be essentially like using the same password on two completely separate, unrelated websites.

And the second thing: If you’re deploying software on a weekly basis, how are you going back and verifying that your security tests are still accurate and your security posture hasn’t changed? Clearly, there is a significant need for automation of security testing for microservices and the API world, and that’s not happening. So, if you summarize this in basically one line, what I say is that the secure development lifecycle itself needs to evolve to engage with the microservices architecture, which it has not. Therefore, we see practices that are not optimal in the security of microservices.

Why do organizations lack the needed tooling and automation? Is it a budget issue, a lack of needed skills or something else?

Aggarwal: Certainly, it includes budgetary considerations, so they don’t want to spend the money. Second is that I don’t think CSOs or CIOs currently understand or appreciate the nature of how security has changed. That’s specifically because microservices security can be broken down into multiple tiers. So, one tier could be configuration management, another can be infrastructure security and a third tier could be runtime security. And a fourth, but very important, portion of microservices security is security testing during development — DevOps-focused security testing. That’s where you would get the maximum bang for buck, but there aren’t elegant solutions out there currently to do that. There is a growing awareness, but the awareness isn’t at the level at which it justifies spending.

On the flip side of this problem, we clearly know that there aren’t enough testers out there in the world that will be able to [keep up] with the speed of deployment and test APIs and microservices to a level that is satisfactory with the risk.

Do you think the lack of testers is a core issue as far as organizations not being able to secure things as well as they should?

Aggarwal: Oh, absolutely. Security skill sets in the QA and testing spaces are very limited from a human perspective. We just don’t have enough capable, qualified security QA testers available, period. So, they can’t scale; they’re not going to be able to meet the demands of the industry. From our perspective, we see that a very highly skilled security tester can perhaps test, in a very liberal perspective, a few hundred to up to a 1,000 test cases in a week. Automation can essentially do that in under an hour in some aspects. So, while I don’t think that [automation] displaces the need for security testing from testers, what it does need to do is be supplanted with automated testing.

I’ll give you a very specific observation. We work with some really large technology companies. Very often, they’re dedicating the vast amount of that security testing manpower to around 10% to 15% of that portfolio. The rest of the 85% of that portfolio of applications and software is essentially going untested in many scenarios. A large part of that is because they just cannot find enough qualified people to do that, and it’s very expensive to do that with people.

The post Why security in microservices continues to fall short appeared first on Artificial Intelligence.