Until recently, applications were built using infrastructure components like SQL Databases, elastic search, file share and web servers which can be easily replicated in a developer’s local environment. Once the code is ready to be released, it is taken over by the operations team for deployment in a cloud environment. Access to the production cloud environment is provided strictly on a need basis and is largely limited to accessing logs, metrics and occasional runtime environment access for troubleshooting. Work responsibilities of application developers and operations team were clearly defined. With Kubernetes, this has changed marginally with developers owning some of the operational specifications like service ports, internal DNS and load balancers.
In the last 5 years, 80% of new public cloud functionalities have been around their Cloud Native Platform Services like S3, ApiGateway, DynamoDB, SQS, Azure Storage, Table etc. While these have enabled hyper-scale application functionality, their operational needs have completely merged the boundaries of ownership between developers and operators.
example of a cloud native application.
In most organizations that are using managed services to build cloud native apps, providing a usable and secure local environment to developers has been quite challenging.
Fundamentally there are three key challenges here:
1. Need for secure access from Local Developer Environment:
The starting point towards building a cloud native app is enabling local access for developers to code against these services. Today, there are no viable versions of these platform services that can be run locally. In some cases, one can use a mock implementation using an interface layer on top of a service.For example, in python there is a mock AWS called Moto, but that is typically always out of date. Finding solutions for other languages is even harder and in many cases the solution may be limited to a specific service only. The only working alternative is to set these services up in a sandboxed developer AWS account and distribute access keys to developers for usage in local development. Since user devices are outside the management control of the cloud Devops team, these keys are hard to track. Further security of these resources that have keys distributed to individual developers have no clear ownership.
2. Setup of a cloud native application requires a single Subject Matter Expert (SME) with two skills: Application and Infrastructure.
As an example see Figure 1 which shows the configuration needed to setup an API gateway. On one hand the setup revolves around API specifications, HTTP header transformations and HTTP code handling to name a few. Then there are operational nuances like certificates, access permissions to lambda triggers, security group configuration for RDS and Redis access.
3. Access to production systems on a need-only basis is very hard to implement:
Because the majority of the deployments and troubleshooting now require application developers in addition to operations, just in time security by manually granting and revoking access is impractical given the frequency of the access needed. Developers and devops are now required to have almost equal access. This becomes risky because developers may not be cognizant of all the security and compliance configurations their change may impact. The alternate approach of devops crafting policies for granularity that spans hundreds of configs is laborious and inefficient. Finally the overarching permission required cannot be granted and more-often than not the cloud native components are removed from the product architecture.
To build a successful cloud native application, organizations need to break the silos of developers and devops which requires both (a) Technology and (b) Cultural change.
Current Technology
There has been some good progress made in this direction.
- AWS Cloud-9 is a Cloud IDE provides a great starting point for engineers to provision and write code against AWS services. But it scopes itself to being an IDE and is far from being a devops tool. It requires users to have overarching provisioning permissions and have the know-how to provision the infrastructure. One basically has to use standard AWS CLI to provision the AWS Services. See https://aws.amazon.com/cloud9/faqs/
- Serverless Platform (Stackery, Serverless.io): These are more focussed on purely serverless apps and again, are not applicable to the devops challenges. For example, say the application runs in a Docker container in EKS and needs to consume SQS and DynamoDB.
DuploCloud Solution: A Cloud IDE with a DevOps Platform
After working with hundreds of developers and devops, talking to AWS on their road map and scourging through tons of paid and open source tools, we concede that replication of AWS and Azure platform service’s functionalities in local environments to match the pace of their evolution is impractical. Further We think it will also be impractical to expect a devops engineer to have the required level of application SME and vice-versa.
To solve the local environment challenge, instead of trying to port the cloud native services locally why don’t we port the local developer environment that largely is the IDE, terminal shell and browser and make it run as a sandbox in the cloud side-by-side with the cloud native services. We leverage two great IDEs that already have a version that can be run in the cloud and exposed purely via browsers: AWS Cloud9 and Open Source Visual Studio Code by Microsoft. The infrastructure provisioning of the cloud services is automated with a devops bot that can take high level specification from the engineer and auto generate the configuration with the right set of security configurations. Just-in-time access is natively built in with a single sign on access.
At DuploCloud we integrated an out-of-box Cloud IDE (VSCode) with the Devops bot creating a harmonious co-working space where engineering teams can focus on harnessing the application functionalities of cloud native services with a self-service secure setup with a Devops oversight on security and cost policies.We demonstrated success in both accelerated application GTM timelines as well as bringing about a cultural change in operations that have reduced cost and enabled innovation.
See below a 1-minute demonstration of an engineer building out a cloud native application shown in Figure1 using DuploCloud VSCode IDE and Devops Platform:
The post Solving AWS Access Key Management for Local Development using a Cloud IDE appeared first on DuploCloud.
Top comments (0)