Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
According to Google Cloud documentation, Cloud Dataflow is serverless while Cloud Firestore is fully-managed. If serverless means that the infrastructure and resources are managed by the cloud provider.
Then what's the difference between these two paradigms?
There isn't script definition of these 2 words. Serverless and Fully managed are very close and share the main concept: don't worry about the infrastructure, focus on your business value.
For me, and in most of Google Product, serverless means "pay as you use". No traffic, you pay nothing, lot of traffic, the scaling is automatic and you pay according with the traffic.
Cloud Run, Cloud Function, AppEngine standard, firestore, datastore, dataproc, dataflow, ai-platform are examples of serverless.
Other services are managed but not serverless, like Cloud SQL, BigTable or Spanner. You always have a minimal number of VM/node up and you pay for these, traffic or not. However, you have nothing to worry about: patching, updates, networking, backups, HA, redundancy(...) are managed for you. AppEngine flex belong to this category.
Finally you have hybrid product, like Cloud Storage or BigQuery: you pay as you use the processing (BigQuery) or the traffic (Cloud Storage), but the storage is always billed if you have no traffic.
This is for GCP. If you look for other cloud provider, the definition is not the same. For example, for AWS, Lambda and Fargate are both Serverless product. But with lamba, no traffic = 0 bill, Fargate keep at least 1 VM up and you are charged for this (don't scale to 0).
Be careful, serverless become a trendy and marketing words. Be aware of what it means for you and your use cases!
Difference between serverless and fully-managed concepts in Google Cloud Platform
As per the documentation, Google Cloud’s serverless platform lets you write code your way without worrying about the underlying infrastructure, which is fully-managed by Google.
I would say that there is a small difference in the meaning of the two concepts; however, their meanings do overlap in many ways.
When I think of serverless, I imagine a picture of the code that makes a service or application run. In English, this would be your favorite programming language, runtimes, frameworks, and libraries. You can even choose to deploy as functions, apps, as source code, or containers since the service is fully-managed.
On the other hand, I believe that fully-managed refers to the architecture that a service uses, namely, what is really happening behind the scenes. Google handles the configuring, provisioning, load balancing, sharding, scaling, and infrastructure management, so you can focus on building great serverless applications.
Notice the paradox in my explanation. I hope this helps a bit.
In my experience Google tend to use "fully managed" term with reference to Database and caching layer technologies where you don't have to write any code.
On the other hand "serverless" tend to get used where you have to deploy some sort of code. In most cloud platforms if you write, you own it and you manage it. So Google won't claim fully managed platform for DataFlow.
That's my explanation anyway, happy to be corrected. :)
Be interesting to see what happens if GCP comes up with Serverless database.
Let's take the example of AWS. Aws offers many kinds of computing services, but the most popular are EC2 and Lambda. EC2 is a fully managed service, basically, AWS offers you an empty VM and you install everything you want there. But that means you also have to manage the upgrading of the servers, maintaining it and many other server-related things. Meanwhile in Lambda you just upload your code and AWS takes care of the rest.
Related
I'm working on a SaaS application which at the moment is cloud only. It's a traditional Java web application which we deploy to AWS. We rely on AWS concepts like RDS, S3, ELB, Autoscaling and for infrastructure provisioning AMIs, Cloudformation, Ansible and CodeDeploy.
There is now more and more demand for on-premise deployments by potential clients.
Are there any common approaches to package b2b applications for on-premise deployments?
My first thought would be to containerize the app infrastructure (web server, database, etc) and assume a client would be able run images. What are you guys doing and how do you tackle HA and DR aspects which come with cloud infrastructure like AWS?
I'm tackling a similar problem at the moment and there really is no one-fits all answer. Designing software for cloud-nativity comes with a lot of architectural design decisions to use technologies on offer by the platform (as you have with S3, RDS, etc) which ultimately do not cross-over to majority of on-premise deployments.
Containerising your application estate is great for cross-cloud and some hybrid cloud portability but there is no guarantee that a client is using containerised work-loads on their on-premise data centre which makes the paradigm still a way off the target of supporting both seamlessly.
I find another issue is that the design principles behind cloud-hosted software are vastly different to those on-premise, with static resource requirements, often a lack of ability to scale etcetera (ironically some of the main reasons you would move a software solution to a cloud environment) so trying to design for both is a struggle and I'm guessing we will end up with a sub-optimal solution unless we decide to favour one and treat the other as a secondary concern.
I'm thinking maybe the best cross-breed solution is to concentrate on containerisation for cloud hosts taking into account the products and services on offer (and in the roadmap) - and then for making the same software available to clients who wish to use on-premise datacenters still.... perhaps they could be offered VM Images with the software solution packaged in... then make this available on a client portal for them with instructions on installation/configuration.
... I wish everyone would just use Kubernetes already! :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Pivotal gives you option to deploy your application with help of Cloud Foundry inside AWS Cloud. I am little confused how PCF and AWS are differ. I know that PCF gives solution using which host (client) can make their own cloud on-premises.
AWS do not provide anything like that. And has lot of other services for elasticity, agility and scalability.
But these two are huge in terms of offerings. Please help in differentiating these two.
PCF is a commercial cloud platform (product) built by Pivotal on top of open source Cloud Foundry. PCF can be deployed on AWS, GCP, OpenStack, VMware vSphere, and some other IaaS platforms.
You should consider using PCF if you want to run your own cloud platform and you don't want to start from scratch.
When using PCF, you can deploy, configure and operate other products provided by Pivotal and their partners, or build your own ones based on your needs.
A typical use case for PCF is when companies want to deploy their applications on-premises for any reason (cost efficiency, flexibility, legal regulations, control over infrastructure, etc.). In this case they decide to use PCF as a leverage to build and operate their own (private) cloud offering. Another use case is when companies don't want to depend on the underlaying IaaS infrastructure. In this scenario, they rely on the fact PCF is IaaS agnostic to give them the ability to migrate if they need to.
These can help you in finding the real difference between PCF and AWS.
https://aws.amazon.com/types-of-cloud-computing/
https://cloudacademy.com/blog/cloud-foundry-benefits/
In two line:
PCF - can be used as PaaS -[Platform as a Service]
AWS - can be used as IaaS -[Infrastructure as a Service]
The most distinct difference between IaaS and PaaS is that IaaS offers administrators more direct control over operating systems, but PaaS offers users greater flexibility and ease of operation.
SaaS examples: BigCommerce, Google Apps, Salesforce, Dropbox, MailChimp, ZenDesk, DocuSign, Slack, Hubspot.
PaaS examples: AWS Elastic Beanstalk, Heroku, Windows Azure (mostly used as PaaS), Force.com, OpenShift, Apache Stratos, Magento Commerce Cloud.
IaaS examples: AWS EC2, Rackspace, Google Compute Engine (GCE), Digital Ocean, Magento 1 Enterprise Edition*.
referece: bigcommerce
So, technically Pivotal Cloud Foundry is a cloud abstraction framework. It's intention is to wrap preexisting commercial cloud offerings to allow adopters to be protected (to a degree) from solution lock-in (here meaning that, the PCF Cloud API is a mapping and abstraction layer over other cloud delivery systems. It's core advantage is that you can always choose the cheapest provider without needing to rebuild your delivery / deployment infrastructure.
It's basically a re-imaging of the HAL concept (if your familiar with that) but instead of enabling the choice of hardware with a single software solution, it enables choice of cloud.
Main reason for using PCF is to enable a person to advantage from competition. Cloud solution providers want to specifically seek to couple you to their particular flavor of system so it takes alot of effort to change away from them so that they can easily adjust their costs (e.g. increase prices) because customers are sufficiently dependent on their particular service and there is a cost for the customer to switch.
Pivotal may offer a cloud of their own, but the idea of the open source cloud foundry is to not force that choice on the business or consumer.
I'm a noobie to CloudFormation. But reading the documentation for CloudFormation, Amazon seems to think it is the method we should use to consistently, repeatedly deploy a given topology of AWS service instances. However AWS has been around for over a decade, and the AWS push for CF seems to be only within the last 5 years.
I stumbled across a great post, AWS OpsWorks vs AWS Beanstalk vs AWS CloudFormation?, which explores the strengths of different AWS deployment offerings. And given the needs of my organization for flexible and repeatable IaaS/PaaS deployments, CF seems to fit the bill.
What I want to know is: How prevalent is the use of CF, vs other "template" deployment technologies? What is YOUR team using for deploying repeated configurations of AWS services?
How usable/learnable is it? If I adopt CF, how likely is it that existing developers on AWS will already be familiar with it, and be able to use it straight off the bat? CF seems to support many or most AWS services already, but are people actually using it to repeatedly stamp out identically-configured topologies of services?
Or do most teams favor a simpler, less endlessly-configurable option? And if so, why?
What pitfalls do I need to watch out for when using CloudFormation Templates? What doesn't CF handle, which it really should?
I'll try to answer most of your questions based on my personal experience:
What I want to know is: How prevalent is the use of CF, vs other "template" deployment technologies?
I can't assert to specific usage distribution, but I know people who use Terraform. Although Terraform supports CF, my team decided not to use it simply because CF already satisfies our needs.
What is YOUR team using for deploying repeated configurations of AWS
services?
My team uses CloudFormation (without Terraform) to deploy our whole infrastructure to AWS
How usable/learnable is it?
Pretty easy. Start with a small template (ideally YAML), then build up from there. The aws cloudformation deploy will speed up your feedback loop.
If I adopt CF, how likely is it that existing developers on AWS will already be familiar with it, and be able to use it straight off the bat?
I think developers who are familiar to AWS can easily pick up CF. If you can find your way around AWS documentation, CF is just another service to learn. I can't assert to the likeliness that existing AWS devs are familiar with CF.
CF seems to support many or most AWS services already, but are people actually using it to repeatedly stamp out identically-configured topologies of services?
My team uses it to provision testing and production environments that have the same topology. Some parts of our infrastructure is duplicated for redundancy using shared CF templates.
What pitfalls do I need to watch out for when using CloudFormation Templates?
You have to watch out for some CF limits, namely the template body's maximum size, which is capped at 46KB. We have hit this limit a few times, especially when provisioning EC2 instances with larger user data scripts. That being said, you should not hit that limit early on, and there are many workarounds
What doesn't CF handle, which it really should?
From the top of my head: Elastic Transcoder, EC2 AMIs, API Gateway VPC Links. My team has circumvented these limitations using Lambda-backed custom resources, which allow you to extend CF to your needs.
Overall, my team is very satisfied with CloudFormation. It definitely helps us maintain our AWS accounts in order.
Hope this helps!
Last month there was an outage in AWS and some sites had to be taken down because of that. I was wondering if a company is availing both AWS and Google Cloud Platform for hosting, how easy would it be for them to easily transfer their services from the Amazon platform to the Google platform or vice versa ( In case Google Cloud has some outage) . First of all is it possible or not? And also if it's what would be the cost for performing such an activity and how much time will it take to get the services running back again.
In this I also did some digging up and what I came across was each of the providers (Google and Amazon) have tools of their own to do so i.e. for transferring the stored data from other platforms to their platform -
https://cloud.google.com/storage/docs/migrating?hl=en
https://aws.amazon.com/importexport/
Are these the only options available or there is anything else as well. Hope some AWS/Google cloud expert would be able to answer my question.
You would need to run your application in both environments, keep the deployments in sync, keep the databases in sync, etc. That can get complicated and expensive...
Then to automatically fail over from one environment to another you could use a DNS service such as DynDNS Active Failover that monitors the health of your application and starts sending traffic to the other environment if your primary environment becomes unhealthy.
How you manage deployments, how you continually ship data across environments, how much all that will cost, all those questions are extremely specific to the technologies (programming languages, operating systems, database servers) you are currently using. There's no way to give details on how you would accomplish those tasks without having all the details of your system.
Further, if you are using proprietary technologies on a specific platform, such as Amazon Redshift or DynamoDB, you might not find a service on the other platform that provides the same functionality.
I've seen this subject come up a lot since the last AWS outage, but I think maintaining two environments on two different platforms is overkill for all but the most extremely critical applications. Instead, I would look into maintaining a copy of your application in a different AWS region, and use Route53 health checks to fail-over.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are getting ready to deploy a new app in the Amazon cloud, using EC2, RDS, and elastic load balancers. RDS would be sharded. Looking at the difficulties of manageing and monitoring anything beyond a few servers, one can see how quickly the task could become pretty crazy. Amazon's interfaces allow you to do all this, but we would have to script it all ourselves.
I was wondering what others have done. There is RightScale, for managed solutions. Has anyone found any other companies, or open source frame works, that do this kind of thing? Looking at:
Monitoring EC2, load balancers, RDS.
Spinning up new instances of the above automatically on predefined load levels.
Sending alerts and taking resources offline automatically when thesholds occur.
Promoting new software/upgrades in PHP and MySQL.
Taking numbers of servers offline for maintenance/troubleshooting.
Any thoughts would be much appreciated.
The type of services you are looking for - automated provisioning, scaling in/out and monitoring is generally referred as PaaS - Platform as a Service. The idea is that you submit your application to the PaaS system and it manages the complete life-cycle of your application.
There are several PaaS providers available that might fit your needs. There's a comparison available here: Looking for PaaS providers recommendations
You should consider your requirements carefully and see which provider is right for you in terms of:
Cloud Support: Do you need just EC2 or maybe additional clouds?
Language support: Some providers target specific coding frameworks and languages
Support
Pricing
Open/Closed source
Disclaimer: I work for GigaSpaces, developer of the Cloudify open-source PaaS Stack.
You could have a look at scalr. They offer this services on their own platform but you can also download the software they're using and set it up on your own.
After Amazon EC2 they started expanding into other cloud services as well, so you can run your scalr managed instances on literally all huge cloud providers.
Very feature rich, but so far I haven't tested it by myself.
You could try Xervmon. They offer integrated cloud management suite of tools to deploy, manage, monitor Amazon AWS along with several other providers. They do offer managed services as well.