I was going through the article https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance#how-different-is-eureka-from-aws-elb about Eureka when I came across this term. Also quite confused what the paragraph means (EC2 classic and AWS security groups). It said
AWS Elastic Load Balancer is a load balancing solution for edge services exposed to end-user web traffic. Eureka fills the need for mid-tier load balancing. While you can theoretically put your mid-tier services behind the AWS ELB, in EC2 classic you expose them to the outside world and thereby losing all the usefulness of the AWS security groups.
I'm completely new to Microservice architecture and reading articles from sources I can find. Any help would be helpful!
A mid-tier load balancer is a load balancer that isn't exposed to the Internet, but instead is intended to distribute internally-generated traffic between components in your stack.
An example would be the "order placement" (micro)service verifying prices by sending requests to the "catalog item details" (micro)service -- you need a mid-tier load balancer in front of the multiple nodes providing the "catalog item details" service so that the request is routed to a healthy endpoint for that service, without "order placement" needing to be responsible for somehow finding a healthy "catalog item details" endpoint on its own.
Eureka was first committed to Github in 2012. Back then, much of EC2 was still running inside "EC2 Classic" -- in simple terms, this is the old way EC2 worked, before VPC. It was a much more primitive environment compared to today.
With EC2-Classic, your instances run in a single, flat network that you share with other customers. With Amazon VPC, your instances run in a virtual private cloud (VPC) that's logically isolated to your AWS account.
The EC2-Classic platform was introduced in the original release of Amazon EC2. If you created your AWS account after 2013-12-04, it does not support EC2-Classic, so you must launch your Amazon EC2 instances in a VPC.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-classic-platform.html
EC2 Classic supported security groups for securing access to EC2 instances, but Elastic Load Balancers (ELB) inside EC2 Classic did not.
VPC became generally available in August, 2011.
Elastic Load Balancer -- originally the only type, this type was later rebranded as "ELB Classic," and is not recommended for new environments -- was released for VPC in November, 2011 but only in the Internet-facing variety. Before this, as noted above, ELB only worked in EC2 Classic, only faced the Internet, and accepted HTTP and HTTPS traffic from everywhere. You couldn't control access with security groups.
ELB Classic learned a new trick in June 2012, with the release of Internal Elastic Load Balancers -- accessible only from services inside the VPC. These could be used securely for mid-tier, but they were very limited because they could not make routing decisions based on hostname or path. ELB Classic was a very barebones load balancer with very little flexibility. You'd essentially need a different balancer for each service. One commom configuration was to use HAProxy behind ELB Classic to fill in some of the feature gaps.
AWS didn't have a solid, managed, mid-tier load balancer offering until August, 2016, when the new Application Load Balancer was announced -- with the ability to send traffic to different backend target groups based on pattern matching in the request path sent to the balancer... and with support for deploying in an Internet-facing or internal-only scheme.
In April, 2017, Application Load Balancers were enhanced with the ability to also select a back-end target group based on pattern-matching the HTTP Host header and/or the path, as before.
At this point, VPC and ALB fill many (but, in some cases, not all) of the needs that seem to have driven the development of Eureka.