We envision a world where the connection is the network: cloud services, connected devices and endpoints, easily and securely connect to each other, any time, anywhere.
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.
For detailed step by step instructions including videos and examples, see the entire Dev.To: Solve your cloud access problems in less than 5 minutes article.