Stratio Microservices

Stratio Microservices Framework is a set of components to manage microservices lifecycle at Stratio Platform. It's composed by several
components that provides:

A way to develop microservices following the best design principles and patterns
Integration with core components of the Stratio platform, such as centralized logging and monitoring
Secured Integration with core datastores presented in Stratio Platform, needed to cover any use case in an operational architecture

1 Lifecycle
2 Framework Components
2.1 Stratio Microservices Archetype
2.2 Stratio Microservices Parents / Starters
3 CICD Components
4 Stratio Core components integration
5 Stratio Core Datastores Integration
6 Security
7 Best practices developing microservices

Lifecycle

The lifecycle of a microservice component in Stratio Platform is represented in the following diagram:

The diagram is following the lifecycle of a particular microservice developed and deployed in Stratio platform (light green boxes). There are
interactions with several components and processes in Stratio Platform to introduce a microservice in such a pipeline. Main components
involved:
 Stratio Microservices Framework artifacts: Artifacts acting as entrypoint and dependencies of a particular microservice to solve the
needed integrations to cover a particular set of use cases
Stratio CICD components: A collection of components to build, test, analyze and deploy microservices artifacts in Stratio Platform
Stratio core components: A set of main components / solutions to cover non functional needs when working with microservices in Stratio
Platform.
Stratio core datastores: Stratio is a multidatastore platform. Depending on the use cases to be covered, microservices would be
integrated with such a datastores

Framework Components

As shown in the diagram, there are some artifacts composing the Stratio Microservices Framework. Let's review the most important ones:

Stratio Microservices Archetype

The archetype is the starting point for any developer when creating a new microservice for Stratio Platform. This archetype provides you a
project prototype that includes:

General SpringBoot v2 Main Application

Common dependencies based on Stratio parents plus some extra added dependencies, from Stratio & 3rd parties. Depending on the
chosen parameters, such a dependencies, packaging to cover the integrations and needed securization is either included or not.
All needed files to build and deploy your application through CI-CD pipeline
Packaging prototype based on Hexagonal Architecture Scaffolding

To generate a new project just run:

Several parameters must be set to create a new microservice. With those parameters, developers can decide if they want to create a new
microservice to expose REST endpoints, to be introduced in an event driven architecture, if there will be a datamodel to manage in the
microservice, if a cache will be present...

Stratio Microservices Parents / Starters

There are several parent artifacts acting as BOM and providing starters to manage Stratio integrations for a particular microservice. A
microservice generated using the archetype will be introduced in a POM hierarchy composed by such an artifacts. As represented in the diagram:
As explained in the diagram, there are three layers composing the POM hierarchy on top of a particular microservice:

Stratio Microservices Projects Parent: Responsible of managing versions for dependencies and plugins commonly used by Stratio
when developing microservices. Not involving core components, but needed components when developing production class
microservices according to our experience.
Stratio Microservices Parent: Responsible of managing versions for core dependencies and plugins. Spring Boot and Spring Cloud
dependencies versions are managed here, apart from dependency versions for core Maven plugins. Starters artifacts to manage Stratio
Platform integrations are located here as well. They are a set of autoconfiguration beans available once the dependency is declared at
microservice's POM.
Stratio Parent: Base parent of any component based on Java - Maven Stack at Stratio.

CICD Components

A set of components needed to introduce a microservice in a Continuous Integration / Continuous Delivery process. A high level vision of the
pipeline:
 1. A developer interacts with Stratio GitLab repository of a particular microservice using "git push" command for a feature or hotfix branch.
2. A PR is created to merge code to integration or master branch, depending on the nature of the source branch to be merged.
3. A PR is reviewed and merged to integration or master branch. Such a branch has a webhook configured to interact with an already
created Stratio Jenkins job for this particular microservice.
4. Jenkins job is triggered and, depending on the nature of the branch, Build, Test, Quality Gates, Delivery and Deploy phases are
executed. Delivery phase interacts with an Artifact Repository based on Stratio Nexus, and Deploy phase retrieves an already created
Docker image for microservices and apply a layer with the created JAR artifact to be deployed interacting the the Container Orhestration
API.

A complete documentation of the CICD pipeline and components involved, are managed by the Stratio Automation Chapter

Please, ask for permissions or credentials of the linked documentation if needed.

Stratio Core components integration

Core components in Stratio are managed by product team in order to provide:

KMS (Key Management Solution) in Stratio Platform: Stratio Vault

A Centralized Logging Solution based on ESK stack (ElasticSearch / Syslog / Kibana)
A Monitoring Solution to collect and trace metrics (Prometheus / Kibana / Alert Manager)

Microservices must be integrated with such a technologies to:

Manage their own secrets (certificates and password) to be used when connecting to backends, exposing interfaces in a secure way...
Forward their formatted logs to be indexed and analyzed
Expose their metrics to be collected, analyzed and alarmed

Documentation for core components is maintained by Stratio here. Please, ask for permissions or credentials of the linked documentation if
needed.

Stratio Core Datastores Integration

Stratio is a multi datastore platform. Depending on the use case, microservices could be integrated with one or serveral of the following
datastores:

Stratio Postgres
Stratio ElasticSearch
Stratio Kafka
Stratio HDFS

Such an integrations are managed by the Stratio Microservices Framework since the microservice is created using the archetype. Depending on
the developer's choice, starters to manage those integrations and the way to get the needed certificates to connect to them securely will be
automatically adapted to the microservice.

Please, ask for permissions or credentials of the linked documentation if needed.

Security
Interface security. Running microservices at Stratio Platform can expose several interfaces to be consumed by clients:

JWT secured HTTPS based interface (REST): When a service is exposing endpoints via REST, an API Gateway is commonly used to
manage the different routes of such a service. Our choice in this case is Kong. Kong will validate and propagate presented JWT (JWS) to
a particular microservice. This JWT represents an Oauth2 Access Token and is previously generated by the operational security layer,
which is based on CAS and, potentially, other services to profile API security access.

Data Access Security. Running microservices at Stratio Platform can be integrated with several components as explained in previous sections.
To manage the secured access to them:

Messaging based interface (Kafka): Services need to present a valid client certificate to communicate with Stratio Kafka. Service identity
must be profiled previoulsy with permissions enough to perform the desired actions.
JDBC connection to Stratio Postgres: Services need to present a valid client certificate to communicate with Stratio Postgres. Service
identity must be profiled previoulsy with permissions enough to perform the desired actions.
HTTPS connection to ElasticSearch: Services need to present a valid client certificate to communicate with Stratio ElasticSearch.
Service identity must be profiled previoulsy with permissions enough to perform the desired actions.
Connection to HDFS: Services need to present a valid client certificate to communicate with Stratio HDFS. Service identity must be
profiled previoulsy with permissions enough to perform the desired actions.

All those profiling actions must be defined and executed in Stratio Gosec management tool.

Please, ask for permissions or credentials of the linked documentation if needed.

Best practices developing microservices

When developing microservices in Stratio, several things must be ensured to be successful:

 Good domain objects definition and relationships. Defined together with the domain experts to maintain a consistent Ubiquitous
Language.
A particular microservice must be created to manage a very limited set of responsabilitites inside its domain.
Self contained, loosely coupled, CICD integrated and managed by a team.
Microservices are distributed by design! Check CAP theorem and ask questions to yourself: Do I need strong consistency here? Do I
have to ensure availability? What if a network partition occurs?
Choose the best communications pattern according to your use case. Don't be rigid... Maybe a sync orchestration is needed in one point,
but try to keep things as decoupled as possible!
Internal technical architecture following the Ports and Adapters pattern, to keep business logic pure and isolated from particular infra /
interface details.
SOLID principles as the "bible" when coding.

Stratio Microservices Framework, when using the archetype, will create a microservice seed prepared to apply a Ports And Adapter pattern out of
the box. Enable the "includeExampleObjects" parameter to checkout an example of a very simple service with several infra interactions involving
REST, Kafka...

Please, ask for permissions or credentials of the linked documentation if needed.