At my company, about 2 years ago, we began the process of re-architecting our 15 years old ‘web site’ by
- breaking up, and rewriting the monolith
- moving our web apps from Contegix ISP to AWS/EC2s
that is: Moving our Infrastructure from ISP to AWS/EC2s
We are moving from about 9 or 10 physical servers in a Data Center, servers which are running our applications
- Website{MySQL DataBase server, 2 Nodes/Servers running Tomcat}
- Analytics Tool{ES+Kibana}
- IssueTracker{YouTrack}
- Test Server + C.I Tool/Jenkins
- CMS Web Application
- REST APIs
- Log Index {ELK}
- Social Notifications module
Into running the new Microservices/Modules on AWS EC2s
We took just one (small) step/improvement from physical servers to IaaS (AWS EC2s)
The PROs of this decision
- AWS IaaS(EC2s) it is within our competencies area
- the generic Cloud Advantages over physical servers in a Data center
- bring up/down EC2s faster than commissioning/decommissioning physical servers
- better availability/reliability/up-time?
reliable networking, reliable servers(machines)
About 2 months ago one our server nodes running the website had a critical hardware failure, and needed to be replaced by a new machine.
This will/shouldn’t not happen in AWS(!?) - flexibility, you can spawn and kill new servers as you wish
- independence, ownership and self-reliance: In AWS you build it, you Run it.
It forces you handle aspects like:- incidents recovery – a Node is down, you have to have monitoring and incident recovery. There is no on-call personnel to restart your servers
- monitoring – you will not receive urgent emails from your ISP telling you that your site/service is down
- You own the infrastructure
You describe the Servers, Networking, Storage in CloudFormation and AWS materializes
The CONs of this decision(compared to Docker/Containers)
- an Increase in number of required EC2s
Because we’re breaking up the monolith in smaller MicroServices/Modules/web applications, and each is deployed in a separate/dedicates EC2… it means we will double the number of server that we need. Whereas, if we would have gone for Docker/Kubernetes we could have optimized this and run multiple services in a container engine
But we didn’t had the know how/technical skills
- Monitoring is harder/resource consuming
Our Infrastructure engineer built monitoring from scratch and it was time-consuming
He installed Grafana Iflux DB, Nagios Alerts, Agents on Servers, etc…
And you have to integrated and build Grafana Dashboards for each new module
But if you use Kubernetes, you have some monitoring built in
- You have to cater to your EC2s, keep them up-to-date with latest Patches, Security Updates , etc… – and you have to do this for every EC2
Into Java 