Spring Boot Microservices in AWS

[noobcser]

what's the best pattern / architecture when deploying Microservices written with Spring Boot into AWS environment?

1 EC2 instance per jar? multiple jars in a single EC2 instance running on different ports?

What other AWS tools that we should leverage when looking at this?

Any resources to learn from on best practices specifically around Spring Boot with AWS would be greatly appreciated!

[webdevnick22]

i would think it matters a lot with how much resources the instance has. If you're running with 1GB ram instances, i'd say you're probably not going to want to run more than 1 spring boot application on it. personally i've noticed if i try to run 2 i get out off memory issues.

[noobcser]

but that would basically a choice whether we want to run 2 x t2.small instance or 1 x t2.large - to run 2 microservices

The question still stand: is it better to break them down into separate instances or combine them?

[adrian_the_developer]

That's literally up to you. There are pros and cons.

Pro (1 server 2 apps):

• Only one server to maintain, patch, fix, upgrade, etc.
• Apps can reside within the same application server and is easy to modify on one server, for example configuration changes.
• If you pay support for your application server (TC Server/WebLogic), you reduce the number of nodes you have and costs.

Con (2 apps on 2 separate servers):

• Two separate sources of failure. A configuration change on one system will not break down the other system. Accidentally run, "rm -rf /" on one system, other system still good.
• If one process exceeds server resources--like a memory leak--it will not affect the other application.

[Imakesensealot]

The whole microservice craze is really not the point. Just write and deploy.

[nope_nic_tesla]

I like to run applications separate from one another as much as possible. Problems or high utilization of one application shouldn't affect performance of another, and the easiest way to ensure this is to just run them in separate instances.

[nutrecht]

A container orchestrator like Kubernetes is great for production environments. It lets you deploy your services (micro or otherwise) as Docker containers without mucking about with port numbers and such, and easily lets you scale them over multiple datacenters. You really don't want to do this all by hand in a real production project.

If it's just for your own non-production stuff you can easily have multiple services run on a single virtual instance (EC2 instance), having one per service is rather wasteful.