Risk Analytics in a Microservices Architecture: Part 2
As this series continues, learn everything you need to know about microservices, including how to secure them, common issues and concerns, and more.
Join the DZone community and get the full member experience.Join For Free
In the first part of this series, we discussed the benefits of microservices that are driving its popularity. The agile, resilient, and open nature of a microservices architecture are all significant benefits you get at first sight, but nothing is perfect. What about the long haul?
This Q&A goes further into the implementation of microservices, and some of the positives and pitfalls that may come as you get into the long haul.
How Have Microservices Changed Application Development?
The vision to create a loosely-coupled enterprise environment has been a Holy Grail for some time. While the same theories and techniques showed promise with XML and SOAP-based web services, the implementation of microservices better supports an agile approach to development.
The decomposition of monolithic end-to-end processes gives product and process designers and developers the flexibility to create solutions that may be a better fit for purpose. It enables these professionals to define more discrete capabilities, allowing developers to develop discrete functions — a more appropriate solution to the business problem they must solve.
What Are the Most Common Issues You See Affecting the Implementation of Microservices?
Microservices are yet another operational and developmental paradigm shift. These shifts always present challenges to implementation. The architectural maturity of an organization is often the most significant hindrance to adoption and implementation. If an organization is not in a place to facilitate the exposure of microservices, for example, due to legacy systems not supporting open messaging, it will hinder implementation.
Do You Have Any Concerns Regarding the Current State of Microservices?
My biggest concern regarding the state of microservices is the possibility that an organization may not adequately secure its endpoints. Due to the lightweight nature of microservices, it is not a prescriptive technology. By contrast, SOAP is governed by a standards body that ensures prescriptive security recommendations are provided. Microservices are not governed, so the potential roll-out is very "wild west."
What Kind of Security Techniques and Tools Do You Find Most Effective for Securing Microservices?
The efficacy of security techniques and tools depend on the environment into which the microservice is deployed, but let's take a general perspective. Microservices do not lend themselves to the "traditional" mode of security because components are not conjoined, therefore they do not share access to a common data repository (think identity control). To avoid making calls to an authentication service in every instance, using OAuth (Open Authorization) as a delegation protocol can simultaneously ensure the security and agility of the system.
What Do Developers Need to Keep in Mind When Working on Microservices?
When working on microservices, developers must be simple and discrete. A service should not be complicated. It should solve one singular problem. It should be as simple as: Give me seven data points, and I will give you a score. Nothing more.
What's the Future for Microservices From Your Point of View — Where Do the Greatest Opportunities Lie?
One of the greatest opportunities in microservices lies in the potential for reuse. For example, many organizations require the ability to quickly reference employee information to match skill level to a given task. Instead of writing the code to lookup required information every time it is used in a process, the organization could write an employee look-up service to be reused by any process that needs the information.
Which Programming Languages, Frameworks, and Tools Does Provenir Use to Enable the Creation of Microservices?
Provenir implements a development technique called graph theory, rather than implementing a language like Java or Scala. Graphs are designed and developed using Provenir's Studio and deployed to our Decision Engine. As part of the development, users can expose REST-based endpoints. These endpoints enable decisions, analytics, processes, etc., to be exposed as microservices. We also provide tools that enable the testing and documentation of the exposed services.
Published at DZone with permission of Mike LaFleur, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.