There are many challenges that cloud developers face today and many revolve around quick, simple, and consistent access to the cloud resources such as databases. As a developer, you want to build software, not spend your time dealing with setting up your development environment.
Whether you are using an existing database or creating a new one, the process can be painful and take a lot of time. You want to make sure your data is accessible but also private, but sometimes you may be making choices that compromise one goal or the other.
Maintaining “developer” databases to run locally: To stay productive, you may use a database that allows a developer to run a database server locally. The scripts to set up the database must be maintained and only have a small sample of example data. The more database types you need the more CPU, memory and storage the developer laptop needs, for example postgreSQL, MySQL, redis, etc. Such a model is not a full-scale representation of the real-world environment and that makes it difficult to reproduce, debug, or test fixes. Deploying debug versions of your application so you can reproduce an issue with extra logging is time consuming.
Making copies of production databases to run locally: This can put a strain on your laptop, you may have a database that is just too big to run locally, or your data contains PII or other sensitive data that should not be on a laptop.
IP allow lists: You need to hide your open ports on public IP addresses and ports such as 3306 for MySQL, or you open your port for attacks. You can try and use IP lists and security groups, but the problem is that you need to maintain these lists in each environment. As a developer, this can mean access is complicated by the manual process of adding your IP address, or if you move location or work from home where you may not have a fixed external IP address, you are faced with repeated requests to devops to update the access rules. This process can introduce security risks when you don’t remove invalid IP addresses.
Using VPNs: VPNs become more and more complicated and limiting as you expand to multi-cloud or multiple VPCs and accounts that lead to subnet collisions. Such a problem may mean you can only connect to one VPN at a time. You may still end up with an open port that you may try to hide with IP allow lists that are maintained at each location where a VPN is used. We know that VPNs are not as secure as once thought.
All of these issues make on-boarding and off-boarding new developers or contractors much more time intensive tasks, resulting in less time developing or making sure that access is cut off when a contractor or developer leaves.
What if you could have the benefits of access to your cloud resources without any of those problems?
Remote.It enables remote development, staging, and production resources to be directly available as if they are running directly on the developer's local machine. You can start coding independent of your location and multi or hybrid cloud environments.
Deployment is quick and easy: Taking away all of these hassles (Setup typically takes 5 minutes or less).
Access can be granted and removed centrally: With the Organization Management feature, access can be granted specifically by resource, unlike a VPN where you technically get access to the entire LAN. You can create roles that have specific permissions and assign the roles to members of the development team based on their need for access.
Add SAML integration: Where login credentials are controlled by your SAML provider, you just simply manage the role of the user. User management can be handled by either the Desktop Application, Web Portal, or GraphQL API. This creates Zero Trust Network Access (ZTNA).
When you connect to a resource such as MySQL via Remote.It, you will be given a localhost address and a unique port. You can use this in your development environment connection configuration, database query tools, etc. There is no connecting, disconnecting, and reconnecting when you change locations or your laptop wakes up from sleep. These on demand connections will go idle when you are not actively using it and go active when you do.
Setup will be creating a VM which will act as a jump box to reach your database resources, registering it in Remote.It, and then adding the services (access endpoints for the resources).
You will need:
- Remote.It Desktop Application (version 3.5.2 or greater)
- A Remote.It account
- AWS console access to the account which can access the VPC where the database(s) reside
Example provided here is for AWS, but is similar for Google Cloud and Azure.
Step 1: Launch and register your Jump VM.
After signing in to the account and selecting the region where your database is hosted, launch a new instance from the EC2 dashboard. (You can leave the instance type at t2.micro).
Key Pair: Select an existing one for your account or create a new one. This is used for SSH access to this instance.
Network Setting: You can create a new security group and deselect SSH. This will ensure no exposed external ports. Don’t worry you can still access SSH from Remote.It.
Open Advanced Settings: We will be entering the one-line command into the User data field
Open Remote.It and get your one-line command:
In the "User data", field enter #!/bin/sh + return and your copied command
Click “Launch Instance”
Once the instance initializes, it will automatically appear in your Remote.It desktop with an SSH service.
Step 2: Add service endpoints for your database(s).
Get your internal endpoint address or internal IP address for your database (Example of MySQL at AWS show below)
Click “Add Service” and enter required information
In a couple of moments, you will be able to connect to the service.
Step 3: Create your org and/or add your team members (optional).
Remote.It provides a couple of different options to manage access to your resources which even includes limiting access to specific services.
Now that you have Remote.It set up, create the connection(s) you need. Remote.It will provide an address and port that resolves to localhost. Use this in your tools such as MySQL Workbench, PGAdmin, or in your IDE development environment variables where you normally put the address. The address is unique to you, but will be ready on demand whenever you use them. Try switching networks where your public IP changes. This connection is resilient to those changes and doesn’t require a VPN, but you have the confidence that the port(s) are not on the public internet.