How much is too much?
In the world of information security policies, one of the challenges is the organizational practicality of the number of policies – should one make them all individual? Or should they be combined? If you’ve ever gotten tired of having to read a really long policy or a bunch of short ones, then you’ve observed the struggle. It’s not an easy decision.
An example of this complexity is the US Department of Defense’s policy table (see it online here: https://dodiac.dtic.mil/dod-cybersecurity-policy-chart/)
The same consideration goes for API architecture: should it be one large construction (monolith)? Or should it be composed of smaller ones (microservices)?
We’ll look at microservices in this post by checking on three benefits and two challenges.
What are microservices?
Microservices are a software architecture style in which an application is built as a suite of smaller and modular services. Each microservice is a standalone unit performing a specific function and communicating with other microservices through APIs.
What do they look like? Here’s an example diagram from Amazon AWS:
The microservice approach has several benefits, including:
- Resilience: Each microservice is self-contained, so the failure of one microservice won’t bring down the entire application. This makes it easier to recover from errors, including attacks against the API if secured properly and maintains high availability.
- Flexibility: Microservices can be developed in different languages and use different technologies. This provides flexibility to use the best tool(s) for the job and to adapt to changing business requirements and technologies.
- Ease of deployment: Microservices can be deployed independently, so it’s easier than the traditional architecture to deploy new features and updates without negatively affecting the entire application.
Here are some details of these benefits.
Want More Tech News? Subscribe to ComputingEdge Newsletter Today!
Resilience
This is a system’s ability to recover from failures and continue functioning. In a microservices architecture, resilience is achieved by designing each microservice as independently deployable and scalable units. This means that if one microservice fails, the others can continue to operate, and the failed microservice can be quickly replaced without affecting the overall system.
This aspect of independence and scalability is called loose coupling (this term could be its own entry, but I’ll merely include it as a reference in this case).
Here are a few strategies that can be used to increase the resilience of microservices:
- Redundancy: Running multiple copies of each microservice makes it possible to continue serving requests even if one instance fails.
- Load balancing: Distributing incoming requests across multiple instances of a microservice makes it possible to improve performance and increase resilience. Load balancing is an important strategy in securing APIs from DDoS attacks.
- Health checks: Regularly checking the health of each microservice makes it possible to quickly identify and replace failing instances.
- Circuit breakers: With circuit breaker patterns, it’s possible to prevent a failing microservice from affecting the overall system by temporarily stopping traffic to the failing service and returning an error instead. This can help to prevent cascading failures. The benefit of circuit breakers, as mentioned here, “When the number of consecutive failures crosses a threshold, the circuit breaker trips, and for the duration of a timeout period all attempts to invoke the remote service will fail immediately. After the timeout expires the circuit breaker allows a limited number of test requests to pass through.”
Flexibility
A microservices architecture allows for greater flexibility in the development and maintenance of large applications. Microservices are independent and modular, making them ideal for independent deployment and development.
For example, different microservices can be developed using different programming languages, depending on the needs of the service and application. Developers can use the language most suitable for the task at hand, removing the constraint of a single language for an entire application.
Microservices make application changes (e.g., features, updates) easier. Implementing a solution such as microservices policy orchestration while requiring appropriate forethought, can make tasks such as API security changes easier to implement, while also improving defense-in-depth.
The flexibility of microservices allows development teams to respond effectively to changing business requirements and technological advances, and to build and maintain a large, complex application more easily.
Ease of Deployment
There are several factors that make microservices easy to deploy:
- Independence: Because each microservice is self-contained and has minimal dependencies on other components of the system, each can be deployed independently of other microservices. New features and updates can be deployed without affecting the rest of the application.
- Automation: Microservices can use tools such as continuous integration and continuous delivery (CI/CD) pipelines to automate changes. By reducing or removing manual intervention, microservice versions can be deployed faster and easier.
- Containerization: These lightweight, standalone, and portable execution environments allow microservices to be easily deployed on any infrastructure and make it easier to scale and manage the application.
- Decentralized management: In a microservices architecture, each microservice is independently managed. This decentralized approach allows development teams to be more agile.
The benefits of microservices (similar to Service Oriented Architecture, or SOA) have been around for a while. One slideshow of interest is this one about Netflix in 2014.
For a more updated look at major uses of microservices, please check out this article about its use by Amazon, Etsy, Spotify, Uber, and (still) Netflix).
Challenges
Microservices don’t solve all problems, and at the same time – as with all technologies – present challenges. Two challenges in using a microservices architecture are:
Complexity
The architecture can be more complex than monolithic architecture because there are more moving parts and more dependencies. This difficulty includes securing the resources. 91% of APIs expose sensitive data, so keeping track of the details is vital to ensuring optimal security.
Integration
Because microservices are designed to be independent, they need to communicate with one another through APIs. This adds complexity to the system due to the increased number of integration points to manage.
As you look to implement microservices, educate your team on the implications and repercussions. There are great benefits, but there are also considerations that require counting the cost before full implementation.
About the Author
Ross Moore is the Cyber Security Support Analyst with Passageways. He was Co-lead on SOC 2 Type 1 implementation and Lead on SOC 2 Type 2 implementation, facilitated the company’s BCP/DR TTX, and is a HIPAA Security Officer. Over the course of his 20 year IT career, Ross has served in a variety of operations and infosec roles for companies in the manufacturing, healthcare, real estate, business insurance, and technology sectors. He holds (ISC)2’s SSCP and CompTIA’s Security + certifications, a B.S. in Cyber Security and Information Assurance from WGU, and a B.A. in Bible/Counseling from Johnson University. He is also a regular writer at Bora.
Disclaimer: The author is completely responsible for the content of this article. The opinions expressed are their own and do not represent IEEE’s position nor that of the Computer Society nor its Leadership.
The post 5 Things You Should Know About Microservices first appeared on IEEE Computer Society.
0 Commentaires