I'm trying to figure out, how the Cloud Foundry Certified Provider Program is tackling vendor lock-in. I've read that it enables Developers to migrate their apps to another certified provider without bigger problems. I'm not sure how this works since theres is nothing written in the requiremets about supported languages or services.
It seams to me, that this certification only guarantees easy porability for statelass apps which doesn't consume any other services.
Am I right with this assumption?
Cloud Foundry launches PaaS certification to combat vendor lock-in
Related
How can I orchestrate and call cloud services from different providers: Google Cloud, AWS and Azure
We did check workflows, but it seems that workflows are limited in each provider's platform, so if I build a workflow in Azure, I can only include services from Azure, but not from Google Cloud or AWS.
Cloud Workflow is an orchestrator that call APIs. There is a better integration for Google Cloud services (and with Google Security) but you can also use other API, such as other Cloud Provider services API.
You can also use Cloud Composer, based on Apache Airflow, which has a large library of operator that help you to call different services on different platform. Because it's initially (and still) an open source project, it's portable and there is no Cloud Preference on that solution.
If you want an orchestration tool for multi Cloud usage, Airflow should be the best approach because it proposes many operators for each Cloud Provider.
It's open source, well documented, there are many supports and example in each Cloud Provider.
It's also the best tool if you want to be Cloud Agnostic and migrate it easily to any Cloud provider if needed.
If you host Airflow in Google Cloud, you can use a managed solution with Cloud Composer 2 (GKE autopilot).
Cloud Workflow is a good solution if you stay in the GCP world, it's serverless and based on API calls but it is less documented than Airflow for an usage outside of GCP. It's also not Cloud agnostic and strongly coupled to GCP.
I recommend you using Airflow for your need.
Migrating on-premise services and applications to Google Cloud Platform and during an extended transition will be in a blended GCP, on-Prem, third party service provided platform. Looking to standardize on GCP OAuth2 provider with the OpenIdentity provider as single source of authentication and verification.
I have poured over the documentation provided by Google Identity Platform and I see Authorization As a Service which appears to be based on Firebase and is close to what I need/want but not exactly.
The Open Identity provider has an SDK and can be integrated with Web, Server, and mobile device applications. Good!
What I am looking to confirm is that I can also use the OAuth2 SDK to authenticate a user with a token, and then use that token with the OpenIdentity APIs to control user access and features. I know this is entirely possible for the GCP native applications.
Presently it looks like using SAML to integrate with another OAuth2 platform within the Identity Product and then enabling the OpenIdentity provider will meet "most" of my needs. What would be missing would be standardizing on the Google Identity Platform before we migrate all our products and services onto GCP.
The burning question, can I use the OAuth2 implementation with services and apps not hosted on GCP?
The documentation seems to suggest to me yes and no simultaneously.
Any help appreciated at his point.
See Hanley's response above. I had read the documentation available for several identity related products for Google Cloud Platform.
My question made sense to me but it does not translate to those who actually understand the the Identity Platform itself, and even say just one (1) of the integration implementation methods. Reading through the developer docs I caught upon a really important piece of perspective that answered nearly all of my questions.
In case it is helpful:
- Google Sign-in uses #gmail.com (or others) google identities which applications or organizations can leverage
- One can configure, create, import domain user identities using the Google Admin console
- These are both considered domain entities and one can configure single sign-on (OAuth, SAML, 509x, JWT, OICD) for these by using providers, or writing custom providers
- Either permits organizations and projects to utilize IAM and other Security-Identity features within GCP out of the box with minimal overhead
This covers about 90% of my initial use case and once I understood that domain user identities are either Google, or your own private domain identities created through the Admin Console through Group and User management, the remaining 10% was easy enough to solve.
I'm going to stop commenting here as this was key in understanding why things did not make sense, and why Mr. Hanley (thank you for your patience) was unable to answer my question at the beginning.
Hoping this helps someone else.
One thing I dislike about Google Cloud Platform (GCP) is its less baked-in security model around roles/service accounts.
Running locally on my laptop, I need to use the service account's key specified in a JSON file. In AWS, I can just assume a role I have been granted access to assume (without needing to carry around a private key). Is there an analogue to this with GCP?
I am going to try and answer this. I have the AWS Security Specialty (8 AWS certifications) and I know AWS very well. I have been investing a lot of time this year mastering Google Cloud with a focus on authorization and security. I am also an MVP Security for Alibaba Cloud.
AWS has a focus on security and security features that I both admire and appreciate. However, unless you really spend the time to understand all the little details, it is easy to implement poor/broken security in AWS. I can also say the same about Google security. Google has excellent security built into Google Cloud Platform. Google just does it differently and also requires a lot of time to understand all the little features / details.
In AWS, you cannot just assume a role. You need an AWS Access Key first or be authenticated via a service role. Then you can call STS to assume a role. Both AWS and Google make this easy with AWS Access Keys / Google Service Accounts. Whereas AWS uses roles, Google uses roles/scopes. The end result is good in either platform.
Google authentication is based upon OAuth 2.0. AWS authentication is based upon Access Key / Secret Key. Both have their strengths and weaknesses. Both can be either easy to implement (if you understand them well) or a pain to get correct.
The major cloud providers (AWS, Azure, Alibaba, Google, IBM) are moving very fast with a constant stream of new features and services. Each one has strengths and weaknesses. Today, there is no platform that offers all the features of the others. AWS today is ahead both in features and market share. Google has a vast number of services that outnumber AWS and I don't know why this is overlooked. The other platforms are catching up quickly and today, you can implement enterprise class solutions and security with any of the cloud platforms.
Today, we would not choose only Microsoft or only Open Source for our application and server infrastructure. In 2019, we will not be chosing only AWS or only Google, etc. for our cloud infrastructure. We will mix and match the best services from each platform for our needs.
As described in the Getting Started with Authentication [1] page, for service accounts it is needed the key file in order to authenticate.
From [2]: You can authenticate to a Google Cloud Platform (GCP) API using service accounts or user accounts, and for APIs that don't require authentication, you can use API keys.
Service and user accounts needs the key file to authenticate. Taking this information into account, there is no manner to locally authenticate without using a key file.
Links:
[1] https://cloud.google.com/docs/authentication/getting-started
[2] https://cloud.google.com/docs/authentication/
I have a MEAN stack application which needs to be cloud hosted. The management needs it to be portable and that brought me to checkout cloud foundry. However, even for cloud foundry there are many provider options like CF on Azure, PCF , IBM Blue Mix and so on. However, I am not able to understand the differences between them. Can you please point me to something that helps me understand the differences between these various providers and make a decision? Also whats the difference between Azure PaaS and Azure Cloud Foundry?
Cloud Foundry is an open source PaaS and because it's open source, you have the freedom to either:
host it yourself on a variety of IaaS
use a public, multi-tenant Cloud Foundry service
have a provider host a private CF for you
This is very similar to hosting options for Kubernetes for example (even though it's worth mentioning that Cloud Foundry predates Kubernetes by a couple of years).
"Pivotal Cloud Foundry" is a commercial distribution of Cloud Foundry targeted at large enterprises. It has a couple of features not found in the open source version, mostly related to deployment automation and integration of application services like MySQL etc. Pivotal is also a main sponsor of development work on the open source version of Cloud Foundry. PCF on Azure is kind of a "template service" that allows you to quickly deploy a private PCF installation on Azure, so it's to some degree a combination of hosting options 1) and 3).
You specifically asked about the difference between various public Cloud Foundry service providers. Here's the most important points:
data center location and related privacy concerns (PWS runs on AWS US locations for example)
choice of managed application services and plans (e.g. MySQL, PostgreSQL etc.)
pricing for apps and application services
performance (available CPU per Diego Cell on which application containers execute, networking)
Cloud Foundry version and supported features like container-to-container networking or deployment of docker containers
quality and availability of support options, onboarding assistance
availability of legal assurances/contracts you may need, e.g. to comply with EU GDPR rules
Also worth reading: Cloud Foundry explained
Cloud Foundry is an OpenSource PaaS that can run on top of any different IaaS. So you can got to https://github.com/cloudfoundry/cf-deployment and use it to install your own instance of Cloud Foundry on Azure, AWS, GCP, vSphere, OpenStack, SoftLayer ... etc.
PCF is a commercial product from Pivotal based on the OpenSource Cloud Foundry. You buy it and then you install and run it on an IaaS of your choice.
BlueMix is a commercial product from IBM which is also based on OpenSource Cloud Foundry. It is also a set of services based on various IBM products so with BlueMix IBM runs and manages the cloud for you.
Azure PaaS is a set of service from Microsoft for deploying applications which only runs an Azure, while Cloud Foundry can be installed on Azure or other IaaS providers.
As regards cloudfoundry platform
is there the possibility to implement a multi-tenant solution? The customer should be able to manage multi-tenancy from a dashboard or “provider console”
is there the possibility to grant permissions and create access roles on a per-user basis?
is there a control panel where the admin user will have direct access to main services (mysql, mongodb,redis, dea, etc)?
As regards application/web development
Is the code versioning (cvs, svn) implemented as module of cloudfoundry or delivered in the vfabric suite?
Is there the possibility to adopt a workflow to track all the phases of application development (design, development, integration and test, implementation, operation)?
Thanks
Here are your answers:
Cloud Foundry platform is a multi-tenant solution in that it allows for multiple users and each user's applications are shielded from others.
There are two types of roles for Cloud Foundry today:admin and user.
There isn't a UI web application tool as of today. You can access your apps deployed to cloud foundry by using the vmc CLI tool. Accessing services is possible using vmc tunnel. See http://docs.cloudfoundry.com/tools/vmc/caldecott.html
As regarding to web development:
No. However one can look at those as a service...
Workflow is usually tool or process based. There is no offer of an application development tracking tool in Cloud Foundry today.