So I am reading about kubernetes and AWS service offerings. For example, one of the main advantages of kubernetes is load balancing but AWS has this too.
How do all these products tie in with one another? Are lots of them doing the same job? Is it just a case that there are so many tools out there now?
Maybe this isn't the correct forum for this question. If not I can remove, but just feel a bit overwhelmed with all the various options, and wondering if they are all completely different.
AWS offers much more services than load balancing, automating deployment, scaling, and management of containerized applications, which Kubernetes is.
If you mean Amazon EC2 Container Service (ECS), so both of them fast and scalable solutions for container management.
Actually, there is an managed Amazon Elastic Kubernetes Service also, which integrated with other AWS infrastructure, such as security, monitoring, etc.
So, it depends on your needs. You can read compare of AWS ECS and Kubernetes.
UPDATE
Here is a big comparison of managed Kubernetes services across Digital Ocean, Scaleway, OVHCloud and Linode.
Kubernetes is an infrasructure-agnostic framework for orchestrating containers. It can run on your laptop (Minikube), or installed on a couple of EC2 instances in AWS, or in a fully-managed offering from GCP, Azure and other cloud providers. Many users and organizations choose Kubernetes because of this portability.
AWS, OTOH, is a global cloud provider,or hyperscaler, with over 200 different services. It is impossible to cover them all. Nevertheless, if we narrow it to container-centric services: AWS offers its own proprietary orchestration tools: ECS and Fargate.
Related
I have a ASP.NET Core Web API planning to deploy in AWS, I don't have enough background in AWS what is the good package to subscribe in AWS?
My option is Amazon EC2 or Cloud Computing or there is other package for Web API? And my other concern is I also have files to upload by the client need at least of 1 or 2 TB of cloud storage. Can I connect the Cloud Storage services of Amazon to Amazon EC2. I really don't how to start.
You could look at Elastic Beanstalk (EB) as explained in Creating and deploying .NET applications on Elastic Beanstalk. EB is AWS Platform as a Service (Paas) offering which allows you to deploy your code, without managing much or any of EC2 instances, load balancers, security groups and more.
Alternatively, if you can run your app in a docker container, maybe it would be easier to deploy it using ECS Fargate. EB can also be used to deploy dockerized applications.
For storage you can use EFS if you require filesystem-like storage that can be shared across multiple instances, containers or lambda functions.
We are running zookeeper today for configuration management. In many cases, this is the only service we are running ourselves. We are able to find a managednoffering for almost everything from aws RDS, all cloud providers have managed redis, etc.
In AWS or Azure, is there a managed offering that can replace zookeeper?
We have all of our cloud assets currently inside Azure, which includes a Service Fabric Cluster containing many applications and services which communicate with Azure VM's through Azure Load Balancers. The VM's have both public and private IP's, and the Load Balancers' frontend IP configurations point to the private IP's of the VM's.
What I need to do is move my VM's to AWS. Service Fabric has to stay put on Azure though. I don't know if this is possible or not. The Service Fabric services communicate with the Azure VM's through the Load Balancers using the VM's private IP addresses. So the only way I could see achieving this is either:
Keep the load balancers in Azure and direct the traffic from them to AWS VM's.
Point Azure Service Fabric to AWS load balancers.
I don't know if either of the above are technologically possible.
For #1, if I used Azure's load balancing, I believe the load balancer front-end IP config would have to use the public IP of the AWS VM, right? Is that not less secure? If I set it up to go through a VPN (if even possible) is that as secure as using internal private ip's as in the current load balancer config?
For #2, again, not sure if this is technologically achievable - can we even have Service Fabric Services "talk" to AWS load balancers? If so, what is the most secure way to achieve this?
I'm not new to the cloud engineering game, but very new to the idea of using two cloud services as a hybrid solution. Any thoughts would be appreciated.
As far as I know creating multiregion / multi-datacenter cluster in Service Fabric is possible.
Here are the brief list of requirements to have initial mindset about how this would work and here is a sample not approved by Microsoft with cross region Service Fabric cluster configuration (I know this are different regions in Azure not different cloud provider but this sample can be of use to see how some of the things are configured).
Hope this helps.
Based on the details provided in the comments of you own question:
SF is cloud agnostic, you could deploy your entire cluster without any dependencies on Azure at all.
The cluster you see in your azure portal is just an Azure Resource Screen used to describe the details of your cluster.
Your are better of creating the entire cluster in AWS, than doing the requested approach, because at the end, the only thing left in azure would be this Azure Resource Screen.
Extending the Oleg answer, "creating multiregion / multi-datacenter cluster in Service Fabric is possible." I would add, that is also possible to create an azure agnostic cluster where you can host on AWS, Google Cloud or On Premises.
The only details that is not well clear, is that any other option not hosted in azure requires an extra level of management, because you have to play around with the resources(VM, Load Balancers, AutoScaling, OS Updates, and so on) to keep the cluster updated and running.
Also, multi-region and multi-zone cluster were something left aside for a long time in the SF roadmap because it is something very complex to do and this is why they avoid recommend, but is possible.
If you want to go for AWS approach, I guide you to this tutorial: Create AWS infrastructure to host a Service Fabric cluster
This is the first of a 4 part tutorial with guidance on how you can Setup a SF Cluster on AWS infrastructure.
Regarding the other resources hosted on Azure, You could still access then from AWS without any problems.
Is there any PaaS providing from Amazon like Heroku , Pivotal Cloud Foundry, IBM Bluemix?
I know that they have many PaaS helpful services like Amazon RDS for database as a service, Amazon elastic Beanstalk etc which makes blur line between IaaS and Paas concept. but at the end of the day we need to orchestrate all of these thing together. So is there any orchestration providing available from AWS ?
One of the challenges in AWS is that its difficult to draw the line between SaaS, PaaS and IaaS, since there are large number of services available with different functionalities.
However, you can consider AWS Elastic Beanstalk as a PaaS which allows you to provision Web and Database Servers without deeply knowing the underling IaaS aspects of AWS (Though it provisions EC2 instances, Elastic Load Balancers and Autoscaling Groups behind the scene).
If you are planning on using Docker Orchestration, you can consider using AWS ECS as an alternative to docker Swarm.
In addition, there is the AWS Serverless Stack (API Gateway, Lambda) which also can be used to develop applications which is fully managed by AWS.
I'm looking for the easiest and fastest way to manage a microservices scalable infrastructure. I chose to use Docker.
But so far, I've faced some different ways to go.
AWS ECS
AWS Elastic Beanstalk
Docker Cloud
Which one would you go? Why?
There's no good answer, it depends on your infrastructure and costs.
AWS ECS: This is the AWS container offering.
Beanstalk: This is PaaS. If you're wanting microservices/scalability this may not be a good fit.
Docker Cloud: If you're an AWS shop I wouldn't go this route. I'm assuming you are since you didn't ask about Kubernetes, GCP, digital ocean, etc.
Edit:
You're not an AWS shop but you have credit. I'd go ECS. You can squeeze more applications out of a VM with docker than Beanstalk. And if you decide to move away from AWS you can take your containers with you. Not the configuration (task definitions are specific to AWS) but the containers themself can be rebuilt and pushed somewhere else.