what is the difference between public and on-premise cloud?

we  are working on transportation app  and want to use apigee but we need to know the best solution for choosing the type of installation (public or on-premise)
@dchiesa1  please appreciate your response with cons and pros


Solved Solved
0 1 294
1 ACCEPTED SOLUTION

we ... want to use apigee but we need to know the best solution for choosing the type of installation (public or on-premise)

I always recommend using cloud services. Of course, I would say that, I work for Google, I believe in the value of cloud services. The old value proposition for cloud services still hold, but we can repeat them here: The idea is, large cloud services providers (CSPs) like Google are able to run infrastructure like networking, compute, and storage, more efficiently and more securely than most other organizations. There are myriad reasons, but economies of scale and specialization are two big ones. OK , so CSPs are better at running infrastructure than your average insurance company, or auto manufacturer, or grocery store, etc. But why Google? Google provides the most secure cloud, the greenest cloud, the best AI/ML capability, and the best management interface. More here.

That general argument in favor of using cloud services rather than self-managed "on-premises" infrastructure applies to lots of specialized stuff: pure compute or storage, but also ERP, database, CRM, AI/ML, and API Management, and of course lots of others.

So in general, I'd say "embrace the cloud." It's not 2009 anymore.

There are cases in which an on-premises system makes sense, but those cases are shrinking in number as time goes on. In the majority of cases I've seen, the justification for having self-managed infrastructure is regulatory. Some regulatory body says "YOU MUST not permit the data in this system to be sent over non-controlled networks." Cases here are Department of Defense, or government intelligence agencies, or some European or middle-eastern banking cases. These regs apply to databases, API Management, all sorts of systems.

I speak to many customers who "lean toward" on premises systems, rather than cloud, for API Management platforms, without a compelling regulatory requirement. They cite reasons like "latency will be intolerable" and "I don't want to pay for the cloud service."  But these objections generally are not backed by data.  They don't have merit.  They THINK latency will be poor, but they don't have metrics. They THINK costs will be higher, but they haven't considered fully-burdened costs of managing servers and networks. 

Repeatedly I have refuted these objections to the use of cloud API Management. Even in the face of hard data, some customers still don't want to embrace the cloud. It's unfamiliar, it feels disconcerting for an IT organization to delegate control. In fact, in the large majority of cases where customers select an on-premises system for API Management, my impression is that the real reason they do so is because the IT and operations staff don't want to relinquish control of managing servers. "This is what we do, we have always done this, and if we use cloud then we will have less to do, or we will have to learn new things." They don't say these things out loud, certainly. And it's possible no one person has that pure view. But all organizations lean toward resisting change, which means "keeping things the way we always have done them." That is the major reason I see people continue to invest in on-premises API Management, or to be more precise, self-managed API Management platforms. I don't think it's a good reason.

So I think the best option, economically and for security reasons, is to embrace the cloud.  But the title of your post asked a different question. It asked "What is the DIFFERENCE between public cloud and on-premises?"  In Apigee, there is an on-prem (customer managed) option, and there's a public cloud option. The public cloud option is where all of our engineering investment accrues. We build new features for the public cloud and hybrid options (Apigee X and Apigee hybrid, respectively).  We generally do not release new features to the on-premises version of Apigee.  So newer things like GraphQL support, GRPC support, External callout, CORS, distribute trace, Anomaly detection, connectors into cloud services, AI/ML bot detection, Conditional RBAC, property sets, Monetization.... all of those go to hybrid and X, and none of them go to the Apigee on-premises system. 

In short, the difference is: the cloud is the current platform that gets all new features. The on-premises option is basically in maintenance. Fully supported, but few new features.

View solution in original post

1 REPLY 1

we ... want to use apigee but we need to know the best solution for choosing the type of installation (public or on-premise)

I always recommend using cloud services. Of course, I would say that, I work for Google, I believe in the value of cloud services. The old value proposition for cloud services still hold, but we can repeat them here: The idea is, large cloud services providers (CSPs) like Google are able to run infrastructure like networking, compute, and storage, more efficiently and more securely than most other organizations. There are myriad reasons, but economies of scale and specialization are two big ones. OK , so CSPs are better at running infrastructure than your average insurance company, or auto manufacturer, or grocery store, etc. But why Google? Google provides the most secure cloud, the greenest cloud, the best AI/ML capability, and the best management interface. More here.

That general argument in favor of using cloud services rather than self-managed "on-premises" infrastructure applies to lots of specialized stuff: pure compute or storage, but also ERP, database, CRM, AI/ML, and API Management, and of course lots of others.

So in general, I'd say "embrace the cloud." It's not 2009 anymore.

There are cases in which an on-premises system makes sense, but those cases are shrinking in number as time goes on. In the majority of cases I've seen, the justification for having self-managed infrastructure is regulatory. Some regulatory body says "YOU MUST not permit the data in this system to be sent over non-controlled networks." Cases here are Department of Defense, or government intelligence agencies, or some European or middle-eastern banking cases. These regs apply to databases, API Management, all sorts of systems.

I speak to many customers who "lean toward" on premises systems, rather than cloud, for API Management platforms, without a compelling regulatory requirement. They cite reasons like "latency will be intolerable" and "I don't want to pay for the cloud service."  But these objections generally are not backed by data.  They don't have merit.  They THINK latency will be poor, but they don't have metrics. They THINK costs will be higher, but they haven't considered fully-burdened costs of managing servers and networks. 

Repeatedly I have refuted these objections to the use of cloud API Management. Even in the face of hard data, some customers still don't want to embrace the cloud. It's unfamiliar, it feels disconcerting for an IT organization to delegate control. In fact, in the large majority of cases where customers select an on-premises system for API Management, my impression is that the real reason they do so is because the IT and operations staff don't want to relinquish control of managing servers. "This is what we do, we have always done this, and if we use cloud then we will have less to do, or we will have to learn new things." They don't say these things out loud, certainly. And it's possible no one person has that pure view. But all organizations lean toward resisting change, which means "keeping things the way we always have done them." That is the major reason I see people continue to invest in on-premises API Management, or to be more precise, self-managed API Management platforms. I don't think it's a good reason.

So I think the best option, economically and for security reasons, is to embrace the cloud.  But the title of your post asked a different question. It asked "What is the DIFFERENCE between public cloud and on-premises?"  In Apigee, there is an on-prem (customer managed) option, and there's a public cloud option. The public cloud option is where all of our engineering investment accrues. We build new features for the public cloud and hybrid options (Apigee X and Apigee hybrid, respectively).  We generally do not release new features to the on-premises version of Apigee.  So newer things like GraphQL support, GRPC support, External callout, CORS, distribute trace, Anomaly detection, connectors into cloud services, AI/ML bot detection, Conditional RBAC, property sets, Monetization.... all of those go to hybrid and X, and none of them go to the Apigee on-premises system. 

In short, the difference is: the cloud is the current platform that gets all new features. The on-premises option is basically in maintenance. Fully supported, but few new features.