Java naar de cloud met Native Services

De cloud is hot en veel organisaties zijn ook met de cloud bezig. Cloud providers bieden een breed scala aan services waar je gebruik van kan maken. Maar wat betekent het als je een applicatielandschap gaat migreren naar de cloud? Met welke services kom je in aanraking en hoe maak je een keuze welke services te gebruiken?

Om antwoord te geven op deze vragen gaan we een vrij traditionele spring boot gebaseerde applicatie migreren naar de cloud. Deze applicatie (zie afbeelding 1) heeft een MySQL database voor het persisteren van gegevens en heeft daarnaast een koppeling met ActiveMQ om berichten te versturen en verwerken. Dit landschap willen we laten landen in Amazon Web Services (AWS), waarbij we zoveel mogelijk gebruik willen maken van native cloud services.

Het aantal services

AWS heeft een ruim aanbod aan services en veel van deze services hebben overlap met elkaar. Uit al deze services moet je kiezen welke je wilt gebruiken. Hierbij moet je afwegen welke wijzigingen je wilt doorvoeren in je applicatie, hoe hoog de kosten van een service zijn en in hoeverre je gebruik wilt maken van cloud native services.

Java backend

De meest simpele vorm om een spring boot applicatie in AWS te draaien is om een EC2 machine aan te maken, daarop java te installeren en ten slotte je applicatie deployen en te runnen. Dit komt het meeste overeen met hoe applicaties in een on-premise omgeving ook gedeployed worden. “Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides secure, resizable compute capacity in the cloud.”

Het zelf installeren van alle benodigde tools op EC2 kan best wat werk zijn, daarom heeft AWS ook een service genaamd Elastic Beanstalk “AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS.” Bij het aanmaken van een EC2 machine met beanstalk geeft je aan welke Amazon Machine Image (AMI) je wilt gebruiken. Hierop zijn verschillende tools al geïnstalleerd. Mocht AWS geen AMI bieden die voldoet aan je eisen, dan kan je ook zelf een AMI maken.

Containers

Een alternatief voor het draaien van een applicatie op EC2 is om gebruik te maken van containertechnologie. Een container kan je op verschillende platformen laten landen binnen AWS. De native service van AWS voor containers is ECS:

“Amazon Elastic Container Service (Amazon ECS) is a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster.”

Het creëren van een ECS cluster is erg eenvoudig:

Hiermee wordt een container cluster aangemaakt waarop een docker container kan worden geïnstalleerd. De worker nodes binnen ECS draaien op EC2 instanties. Ook voor het creëren van EC2 instanties voor ECS heeft AWS een service gemaakt, te weten Fargate:

“AWS Fargate is a compute engine for Amazon ECS that allows you to run containers without having to manage servers or clusters”.

Hiermee laat je ook het beheer van de worker nodes over aan AWS.

Wanneer je minder afhankelijk wilt zijn van je cloud provider, of zelfs multi cloud wilt, is EKS (Managed Kubernetes Service) ook nog een mogelijkheid.

“Amazon Elastic Kubernetes Service (Amazon EKS) makes it easy to deploy, manage, and scale containerized applications using Kubernetes on AWS.” Met EKS maak je een kubernetes cluster aan waarop je pods kan deployen. Omdat kubernetes niet AWS specifiek is, zou je dit multicloud kunnen inrichten.

Omdat we gebruik willen maken van native cloud services is ECS de beste service om te gebruiken. Het aanmaken van een ECS cluster is heel eenvoudig en integreerd met fargate waardoor we zelf minder hoeven in te richten.

 

Databases

Voor databases heeft AWS een service genoemd RDS (Relational Database Service):

“Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale a relational database in the cloud.”

Met RDS kan je verschillende type databases aanmaken, je kan gebruik maken van MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server en Aurora.

Aurora is een fork van deze producten met een storage layer geoptimaliseerd voor de AWS-infrastructuur: “Amazon Aurora is a MySQL and PostgreSQL-compatible relational database built for the cloud, that combines the performance and availability of traditional enterprise databases with the simplicity and cost-effectiveness of open source databases.”

Voor onze applicatie is Aurora de beste database om te gebruiken. De overgang naar Aurora is minimaal en door de optimalisatie van de storage layer is de performance van Aurora uitstekend.

Queueing

Op het gebied van queueing heeft AWS verschillende services beschikbaar. Het dichtst bij de huidige implementatie komt AmazonMQ:

“Amazon MQ is a managed message broker service for Apache ActiveMQ that makes it easy to set up and operate message brokers in the cloud.”

Met AmazonMQ kan je een managed ActiveMQ instantie afnemen. Deze kun je ook high available maken.

AWS biedt daarnaast een eigen managed service voor queueing, SQS

“Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications.” en voor pub/sub heb je SNS:

“Amazon Simple Notification Service (SNS) is a highly available, durable, secure, fully managed pub/sub messaging service that enables you to decouple microservices, distributed systems, and serverless applications.”

Afhankelijk van je use case kan je van deze service gebruik maken, waarbij je wel moet letten op de beperkingen die deze services hebben, bijvoorbeeld op grootte van de berichten.

 

Als we de applicatie willen aanpassen om streaming berichten te verwerken en willen we dat doen met Kafka, dan biedt AWS een service waarbij een managed Kafka cluster beschikbaar wordt gesteld:

“Amazon MSK is a fully managed service that makes it easy for you to build and run applications that use Apache Kafka to process streaming data.”

In onze applicatie kunnen we het beste gebruik maken van SQS. Deze service biedt de scaling mogelijkheden die we nodig hebben. Het gebruik van Kafka zou te veel afwijken van de huidige architectuur.

 

Next steps

Naast de services die voor de applicatie nodig zijn, zal je ook iets moeten doen met Identity and Access Management (IAM), logging (Cloudwatch), netwerk (VPC), container registry (ECR), etc. Wil je optimaal gebruik maken van de mogelijkheden van de cloud en daarbij ook letten op de kosten (pay per use), dan moet je de software architectuur aanpassen naar de cloud. Denk hierbij aan het gebruik van onder andere Lambda’s, Batch, S3 Glacier (archief storage), etc.

 

Wil je verder onderzoeken hoe deze service gebruikt kunnen worden, maar is de ‘echte’ cloud niet binnen handbereik? Dan is er een alternatief om lokaal aan de slag te gaan met een aantal AWS services. Localstack is een framework dat een aantal services van AWS mockt, hierdoor kan je toch wat ervaring opdoen met AWS services.

 

Conclusie

Er zijn veel verschillende services en keuzes waar je rekening mee moet houden bij een cloud migratie. Tijdens de JFall zal ik een verdere doorkijk geven over dit onderwerp.

In de basis is AWS slechts een ander platform. Je kunt door middel van het aanmaken van EC2 instanties zelf de softwarepakketten installeren zoals je dat voorheen ook deed.

Om optimaal gebruik te maken van de cloud moet je gaan kijken naar de verschillende services die de cloud provider je biedt. Ook hierin zijn verschillende keuzes te maken en moet je je goed verdiepen in de verschillende mogelijkheden en de kosten van een service.

De referentie-applicatie kunnen we op verschillende manier migreren naar de cloud. Zonder te veel aanpassingen te doen aan de architectuur en gebruik te maken van zoveel mogelijk native AWS service komen we op het volgende: ECS + Fargate voor het runnen van de container, Aurora voor de persistency en SQS voor queueing (zie afbeelding 2)

 

Bio Pascal:

Pascal is is software architect bij Quintor.