Is there any technology like CloudFormation for aws that would work on any IaaS based cloud to do the same thing? I mean you write it once and then it runs on any IaaS based cloud platform like azure, aws, openstack, and so on?
I think what you are looking for is exactly OpenStack Heat Project http://wiki.openstack.org/Heat The project is under active development.
Your question is making some assumptions that isn't quite correct - there's a lot of different types of clouds - Google AppEngine, OpenShift, Heroku and Azure (for example) work at a very different layer than the cloud services you get from Amazon AWS, CloudStack, OpenStack, etc.
The first is more of an platform as a service (PaaS) play, the later are more infrastructure as a service (IaaS). That said, and given that you're asking about Amazon's CloudFormation, it's worth mentioning that there's an equivalent of that technology for OpenStack clouds called HEAT (although I'm not aware of one that works with CloudStack).
To answer you're higher level of question of "is there a way to write it once and run it on any cloud?", today the answer is a qualified "no". There's lots of APIs and helper libraries you can use to bring several cloud provider options more into compatibility, and some companies are making all their pennies of exactly this game (enStratus, for example). But none of them go so far as to allow you to "run it anywhere" - especially when you lump IaaS style clouds in with PaaS style clouds.
What you are describing is a Platform-as-a-Service (PaaS) that works on multiple clouds. There is a similar question here: Cloud Mangement for Amazon IaaS
The answers also link to a comparison of PaaS options.
Check out enstratus. It's a UI for interfacing with multiple Cloud APIs. So you can store and shift images between different clouds then spin them up and down. Might be what you want.
Related
Please help me understand why we say azure functions is a serverless compute service. It does require cloud to host it and run. Cloud is also a server still why we are saying it is serverless?
Serverless computing does not mean that servers are out of the picture. Servers are very much required, just like they have been for all these years, or else, where will your code run. The reason why the phrase was coined is that as a developer, you do not need to worry about what server your code runs on. In fact, you do not know which server it eventually runs on. Once your code is deployed, Azure assigns the responsibility of executing the code to the next available server. What Azure ensures, and what is ultimately important for you, is that your code will execute whenever required.
Ref: Serverless Computing with Azure Functions
Hope it makes sense :)
To get a better idea this is how we evolved. Cloud providers are making sure we should only worry about the business logic but nothing else.
IaaS (Infrastructure as a service)
You get a running VM somewhere in the data centre but you are required to maintain everything. From Deployment to patching your VMs or anything running on the VM.
PaaS(Platform as a service)
You are not longer required to maintain platForm but you are still responsible to manage your server in terms of load balancing etc.
FaaS(Function as a service)
Servers are abstracted from you . You are only required to maintain your code without worrying about what's under the hood or how to load balance your servers. It's then cloud provider responsibility to package your code and run it for you. But servers are still there.
Going by the official documentation of Azure Serverless computing service, Azure Functions can be defined as;
Azure Functions is a serverless compute service that enables you to run code on-demand without having to explicitly provision or manage infrastructure. Use Azure Functions to run a script or piece of code in response to a variety of events.
Azure Functions is an event driven, compute-on-demand experience that
extends the existing Azure application platform with capabilities to
implement code triggered by events occurring in virtually any Azure or
3rd party service as well as on-premises systems. Azure Functions
allows developers to take action by connecting to data sources or
messaging solutions, thus making it easy to process and react to
events. Azure Functions scale based on demand and you pay only for the
resources you consume.
Here the serverless compute service is like a metaphor which implies, the end user doesn't need to manage the servers or infrastructure to run the applications over the Azure and can spend time to focus on managing and improving the business logic.
Few more points to consider,
Serverless in Azure builds on an open-source foundation, the core of
which is Azure Functions, an event-driven compute experience and open
source project. Community contributions include support for new
languages, integrations and deployment targets.
Azure Functions can be used on-premises, in hybrid environments such as Azure Stack, on IoT Edge devices and deployed on top of orchestrators such as Kubernetes – as well as in other clouds.
They enable faster time to market with lower infrastructure and operating costs.
There are heaps of definition of serverless which you can easily google. But I will share my understanding anyways.
1. It does require cloud to host it and run.
You are correct with this. But anything on Cloud requires Cloud, doesn't it? Azure being one of the cloud providers consists of hundreds of services to cater to different needs people are after from using Cloud.
2. Cloud is also a server still why we are saying is serverless
This is not quite right. Cloud is different from a server. Server is a physical box sitting somewhere. With hundreds of thousands of servers all over the world, Cloud hosts all sorts of different services on these servers.
The reason we say Functions are serverless is that the infrastructure of hosting a Function is abstracted away from devs. It is still deployed to some servers but Azure is responsible for all the resource managing, configuration, load balancing, scaling and networking etc. It allows developers to focus primarily on their code, not having to worry about servers.
I want to host an Orleans project on Azure, but don't want to use the (classic) Cloud Services model (I want an ARM template project). The web app sample uses the old web / worker model - what is best option? There is a Service Fabric sample - is that the best route? The nearest equivalent to the web/worker model is VM Scale Sets - is that a well tested option?
IMO, app service is closet to web role.
Worker role however, depending on the point of view
From system architecture point of view, I think Scale Set is the closet. You get an identical set of VMs running your application. However you lost all management features. How your cluster handle application configurations, work loads on each node, service interruptions from server failure or deployments are pretty much DIY. Also you need to provision the VM with dependencies for your application.
From operations point of view, I think Service Fabric is the closest. It handles problems above but then you are dealing with design/implementation changes and learning curve from the added fabric layer in the architecture. Could be small, could be big depending on the complexity of your project. Besides, service fabric is still relatively new and nothing is for sure. Best case you follow the sample change a few lines of code and it works like a charm. Worst case you may want to complete refactor orleans solution into service fabric solution.
App service would be the easiest among the three. If it doesn't meet your requirement, I personally would try Service Fabric. Same reason why people are moving to cloud and you would opt for ARM solution.
We have been developing a RESTful web api using node and MongoDB. For hosting options, we decided to use Azure through BizSpark. We used DocumentDB with protocol support for MongoDB.
The problem now is DocumentDB is consuming all the credit causing a downtime and we haven't started making money yet. We are now considering switching from DocumentDB to MongoDB. The question now becomes, what is the cheapest way to host MongoDB on Azure?
So far on our research, we have found two options:
Using a VM (Linux or Windows)
Using a worker role
Please advice if there are other options, and how easy can it be to switch between these options at a later stage.
You can use the Azure calculator to get estimates between DocumentDB and a VM with the settings your company needs to see which one is cheaper.
If you are using Bizspark, remember that you have 5 accounts in which you can distribute all your costs to optimize in a better way.
Personal recommendations(subjective view):
Remember that if you are using the PAAS solution(DocumentDB) you
get full functionality out of the box, you don't have to set it up
and you can escale it very easily and plug in to very powerful tools
like PowerBi out of the box.
In the case of IAAS solution(vms) you have to install, mantain and
create all the connection settings for this to work. If you want to
scale you have to me more dedicated, since you have to scale it
through the use of more vms, traffic managers and more robust
architecture. If this is the path you are taking I would recommend
using containers like Docker inside the VM and their power to
manage this.
After going through several similar questions I am still not entirely sure about the pros and cons of the two approaches; hence this question.
Based on my understanding it is possible to have
Multiple roles (Web and/or Worker) in a single Cloud service.
Alternatively we can have these roles separated in their own Cloud
service (our current approach).
What are the benefits of either approach over the other and particular use cases where either one should be preferred/avoided.
Also how do they compare to each other when it comes to scalability and availability?
When do I choose which? My understanding at the moment is both offer the same except maybe the pricing.
if you did not see that Azure Multitenancy Guidance, i highly recommend to take a look, because they wrote it using Cloud Services as an example and the link above discusses some of the architecture decisions you are asking of.
IMO, it is difficult to say that first approach is better then the second somehow, it depends on what is the scenario in your project.
I would say that one of the important things are the limits of one Cloud Service. If you have the project that has instances that should be unique for the customer, then it can be more difficult to isolate your users if the solution is in the same CS, etc. A lot of decisions - mostly depends on the project specifics.
One difference between the two approaches is in deployment. Cloud services are deployed with all their web roles and worker roles together. If you need to have separate deployment schedules for some of your roles, separating them into different cloud services will allow you to do that.
As for pricing, I don't think there is a difference as cloud services are billed on a "per (role) instance" basis and this does not change between the two options you described.
Looking into it I came to find out that a 1 role of 1 small compute Cloud Service is almost 60% more expensive as the same 1 small "vitual machine"...
So why should i choose to use cloud service over virtual machine?
Searching the web I came across a lot articles about this including this article but none were clear enough for me... the comparison in the last one is plain useless in my opnion...
Is there a "perk" that i don't know about or is not being considered? something to justify the "extra-charge" for cloud service... Does a code running on cloud service perform better than running on a virtual machine (maybe because there's less overhead)? anything?
I think virtual machine would be used when we need to migrate our application to the cloud and make it 'just work'. We don't need many additional effort to move our legacy code to azure if using virtual machine. But it doesn't provide the rich PaaS features comparing with cloud service such as automatically deployment, automatically update, load balance, etc.
So if we have a legacy system and we wanted to quick move to azure, then we can choose virtual machine. But if we need to manage bunch of machines, cloud service would helps us a lot and make us focus on the business logic.