Cloud ML from Google is serverless technology, If serverless architecture doesn’t care about how many servers were created behind the scene then why do we give scale tier option in Cloud ML.
Serverless doesn't mean that your application or process is not running under a server, obviously it is. Serverless is an abstract concept, is a type of architecture where the servers "doesn't exists" to the developer, they don't have to worry about anything, only develop the code, set parameters as you pointed, the maximum number of servers or their Memory utilization (to not to have an enormous bill at the end of the month), and then their app will work and autoscale when it's needed.
Related
When I select "scheduled job" while initiating resources, how is the process handled internally?
Can I verify the container in ECS? I guess it will use batch jobs for this option.
# copilot init
Note: It's best to run this command in the root of your Git repository.
Welcome to the Copilot CLI! We're going to walk you through some questions
to help you get set up with an application on ECS. An application is a collection of
containerized services that operate together.
Which workload type best represents your architecture? [Use arrows to move, type to filter, ? for more help]
> Load Balanced Web Service
Backend Service
Scheduled Job
What will be the charges if I select backend service or scheduled job?
Copilot uses Fargate containers under the hood; therefore, your charges for a backend service are based on the number of containers you have running and the CPU/memory size of those containers. The minimum container size is 0.25 vCPU and 512 GB of reserved memory.
For other service types, your pricing depends on a few more things.
Load Balanced Web Service
Fargate containers based on size and number (~$9/month for the smallest possible container)
Application Load Balancer (about $20/month depending on traffic)
Backend Service
Fargate containers based on size and number (~$9/month for the smallest possible container)
Scheduled Job
Fargate containers based on size, number, and invocation frequency and duration (ie you only pay for the minutes you use)
State Machine transitions The first 4000 transitions in a month are free, which corresponds to an invocation frequency of about once every 21 minutes assuming there are no retry transitions. Transitions after that limit are billed at a low rate.
Other notes
All Copilot-deployed resources are grouped with a number of resource tags. You can use those tags to understand billing activity, and even add your own tags via the --resource-tags flag in copilot svc deploy or copilot job deploy.
The tags we use to logically group resources are the following:
Tag Name
Value
copilot-application
name of the application this resource belongs to
copilot-environment
name of the environment this resource belongs to
copilot-service
name of the service or job this resource belongs to
The copilot-service tag is used for both jobs and services for legacy reasons.
Copilot refers to these entities as common cloud architectures [1].
I could not find an official document which outlines how these architectures are composed in detail. I guess it might be an implementation detail from the creators' perspective when you look at point one of the AWS Copilot CLI charter [2]:
Users think in terms of architecture, not of infrastructure. Developers creating a new microservice shouldn't have to specify VPCs, load balancer settings, or complex pipeline configuration. They may not know anything about other AWS services. They should be able to specify what "kind" of application it is and how it fits into their overall architecture; the infrastructure should be generated from that.
I have to agree that more sophisticated users always ask themselves how costs of a specific architecture will look like and I completely endorse the idea of having a special Copilot command such as copilot estimate costs service-xy which can be executed before creating the service.
There is some high-level documentation on the architecture types Load Balanced Web Service and Backend Service. [3]
It mentions the command copilot svc show in conjunction with the --resources flag [4]:
You can also provide an optional --resources flag to see all AWS resources associated with your service.
I think this gives you the ability to estimate costs right after bringing the services up and running.
A somehow more complicated approach which I frequently apply to understand complex constructs in the AWS CDK is to look at the source code. For example, you could open the corresponding Go file for the Load Balanced Web Service architecture: [5]. Digging into the code, you'll notice that they make it pretty clear that they are using Fargate containers instead of EC2 instances.
That is also what they tell us in the high-level service docs [4]:
You can select a Load Balanced Web Service and Copilot will provision an application load balancer, security groups, an ECS Service and run your service on Fargate.
More on Fargate: [6]
Btw, there is a really interesting comment in the issue section which outlines why they decided against supporting EC2 in the first place [7]:
What features have the team currently explicitly decided against?
EC2 comes to mind. I think we could have built a really nice experience ontop of EC2 instances - but I think there's a difference between building an "abstraction" around ECS / Fargate and building an "illusion" around ECS / EC2. What I mean by that is that if we created the illusion of a fully hands off EC2 experience, customers might be surprised that they are expected to be in charge of patching and security maintenance of those instances. This isn't something that Copilot, a CLI can really automate for people (realistically). We're still trying to figure out a good way to expose EC2 to folks - but we definitely see Fargate as the future.
I started last month in a new company. Where I will be responsible for the infrastructure and the backend of the SAAS.
We currently have one droplet/instance per customer. In the current phase of the company it is a good choice. But in the future when the number of instances grow, it will be difficult to maintain. At the moment there are 150 instances online, each with 1CPU and 1GB memory.
Our customers only use the environments for moments a week, a month or a year. So most of the time, they do nothing. So we want to change that. I am thinking of Kubernetes, Docker Swarm or another tool.
What advice can you give us? Should we make the step to Kubernetes or Docker Swarm, or stay with the droplets / VMs at DigitalOcean, AWS or GCP?
If we move to AWS or GCP our average price will go up from 5$ p/m to above the 10$ p/m.
We want to make the next step to lower the waste of resources but also thinking about the monthly bill. In my mind, it will be better to have 2 our 3 bigger VMs running Kubernetes or Docker Swarm to lower the monthly bill and lower our reserved resources.
What do you think?
If you are serious about scaling, then you should rethink your application architecture. The most expensive part of computing is memory (RAM), so having dedicated memory per-customer will not allow you to scale.
Rather than keeping customers separate by using droplets, you should move this logical separation to the data layer. So, every customer can use the same horizontally-scaled compute servers and databases, but the software separates their data and access based on a User Identifier in the database.
Think for a moment... does Gmail keep RAM around for each specific customer? No, everybody uses the same compute and database, but the software separates their messages from other users. This allows them to scale to huge numbers of customers without assigning per-customer resources.
Here's another couple of examples...
Atlassian used to have exactly what you have. Each JIRA Cloud customer would be assigned their own virtual machine with CPU, RAM and a database. They had to grow their data center to a crazy size, and it was Expensive!
They then embarked on a journey to move to multi-tenancy, first by separating the databases from each customer (and using a common pool of databases), then by moving to shared microservices and eventually they removed all per-customer resources.
See:
Atlassian’s two-year cloud journey | TechCrunch
How Atlassian moved Jira and Confluence users to Amazon Web Services, and what it learned along the way – GeekWire
Atlassian cloud architecture - Atlassian Documentation
Salesforce chose to go multi-tenant from the very beginning. They defined the concept of SaaS and used to call themselves the "cloud" (before Cloud Computing as we know it now). While their systems are sharded to allow scale, multiple customers share the same resources within a shard. The separation of customer data is done at the database-level.
See:
The Magic of Multitenancy - Salesforce Engineering
Multi Tenant Architecture - developer.force.com
Bottom line: Sure, you can try to optimize around the current architecture by using containers, but if you want to get serious about scale (I'm talking 10x or 100x), then you need to re-think the architecture.
We are trying to evaluate the best ways to scale our J2EE web application and use hosting services with AWS. Are there reasons why we would use the Lambda service over Kubernetes (EKS)? Although it seems that Lambda can scale functional units, I'm not clear why anyone would use that as a substitute for Kubernetes, given Kubernetes can replicate containers based on performance metrics.
They serve different purposes. If you want to have horizontal scalability on a "ec2/pod/container" level and handle the availability yourself (through k8s of course), go for Kubernetes.
If you have a straight forward function doing a particular thing and you don't want to bother yourself with operating costs of having to manage a cluster or packaging it, then you can let Lambda administer it for you (at the time of writing, you would pay 20 US cents per million call). It is just another layer of abstraction on top of a system that is probably similar to Kubernetes, scaling your function per needs.
The goal of these technologies is to remove as much overhead as possible between you and the code and infrastructure can be painful. To summarize, serverless is to Kubernetes what Kubernetes is to containers.
To make a conscious decision, take the following into account:
Does your budget covers operation and maintenance of infrastructure
Do you have the expertise in Kubernetes
How much would it cost to redesign your J2EE app into serverless
ready code
Your timeline (of course...)
Based on the AWS resources you will use, how much do you save or not
by implementing a k8s cluster (database service?, EBS, EC2s, etc.)
I have seen instructions for installing Bosh Lite on AWS. It's a similar process to installing it on a local VM. Then I can utilize Bosh to deploy OSS Cloud Foundry to the bosh-lite VM. Here are those instructions:
https://github.com/cloudfoundry/bosh-lite/blob/master/docs/aws-provider.md
My question is how can I estimate how much this would cost? I want to charge this on my company credit card, but I need to estimate the cost first. I know I can get a plain EC2 instance free for a year (I assume there's some limit to how much I use it), but from the looks of the instructions above, I think I'll need several, along with other instances.
So, if I just set up Cloud Foundry, write a simple "Hello World" web app using Spring, deploy my app and test it, and then tear everything down, how can I estimate the cost?
AWS costs vary with the services, regions, data in/out etc.
So list down the aws region you want to use, list all the number of resources & their types (Ex. EC2 - t2.medium) and approximate storage etc everything.
Then go to AWS calculator and feed all those entries and it will show you the costs.
Here is calculator link: https://calculator.s3.amazonaws.com/index.html
I am at the beginning of a large migration from a single monolithic web service to a collection of microservices using Spring Cloud/Spring Cloud Netflix. Through my research of microservices I understand that the lines of demarcation between services should mirror the separations of concerns between them. An additional factor affecting separation is which services are required to scale individually.
As a concrete example, depending on the level of granularity desired, a microservice environment could end up like this:
Accounts (containing Signup, Login, Profiles, etc.)
Store (containing Products, Payments, Reporting, Inventories, etc.)
Chat/Social (containing chat rooms, user statuses, etc.)
...
Or it could end up with each of the areas of concern in brackets represented by their own microservice, e.g:
Accounts
Signup
Login
...
I believe there is a preference in the microservices community for the second approach, and I tend to agree. However, the issue I have is one of hosting and resource limitations.
In the migration I would like to streamline the provisioning of resources and the installation of updated services. Since we use the AWS stack, Elastic Beanstalk seemed like the perfect choice. While researching Elastic Beanstalk though I was rather disheartened to discover that there was a limit of 25 applications per account. Not only that, but EC2 has a limit of 20 instances per region per account. It seems like a microservice architecture will hit that limit very quickly, especially when you add multiple environments (staging and production) for each service into the mix, let alone websites and internal tooling.
With all of the amazing content that I've seen around the web regarding microservices, I'm surprised and somewhat disappointed at the lack of information regarding the actual hosting of microservices beyond the development of them. Have I missed something? Is there any information about deploying more than a couple of microservices on AWS?
It is my understanding that Netflix use AWS for their own microservice hosting, beyond requesting additional resources from Amazon and throwing money at it, are there other solutions? Would their Asgard tool help with this issue (possibly by handling the sharing of instances between services) or would it result in the same outcome?
As mentioned in the above comments, AWS will raise your limits if you have a legit use case - why wouldn't they? they are in the business of selling you services.
But since you have asked for suggestion other than increasing those limits, and since you are in the early stages of designing your solution, you should consider basing part of your micro-services architecture on Docker or another container/container like service (my own preference would be for the AWS's container service). Depending on the nature of you solution, even within the limits of 20 EC2 instances (per region), if you had large enough instances running you could fit dozens (or even hundreds of lightweight) docker images running on each of those allocated 20 instances - so potentially hundres or thousands of walled off micro-services running on those 20 EC2 instances.
Using an entire EC2 image for each of many micro-services you may have may end up being a lot more expensive than it needs to be.
You should also consider the use of AWS Lamba for at least portions of your micro-service architecture - its the 'ultra-micro service' tool also offered by AWS.