The Problem with Publicly Accessible AWS Resources
When you first develop infrastructure for a new project, you naturally optimize for rapid development. You want to get something — anything — out the door, and you therefore want to be able to write code and debug issues quickly.
Because of that, it’s awfully tempting to spin up servers and databases in public subnets so that you can readily connect to them for debugging sessions. It’s nice to be able to ssh my-user@my-web-server to do some live code debugging, or psql -U my-user -h my-database-instance to assess the current state of your database.
Sure, AWS allows you to do that. You can expose SSH on your webservers and you can expose your AWS Relational Database Service (RDS) and Redis/ElastiCache servers to the internet for easy access. But should you? Exposing databases and servers publicly yields a pretty obvious security issue: your sensitive data is directly accessible to anyone on the internet. …
Most modern dev teams have little appetite for spending weeks or months building payment processing from scratch, when they can instead quickly incorporate a SaaS tool like Stripe to handle that functionality. There’s a lot of upside to using a tool like Stripe: it cuts development time, abstracts much of the complexity associated with payment processing, and reduces maintenance effort. That’s pretty darn appealing when you’re racing to get your product to market and staring down a mile-long list of features to build.
The Trend: Incorporate Rather Than Build In-House
It’s not just payment processing, of course. A clear trend in modern software development is that dev teams are increasingly incorporating SaaS tools as components of their applications rather than developing every last bit of functionality from scratch. …
Take a moment and try to put yourself in the shoes of someone who’s just landed a job on a development team. You pored over page after page of job postings, looking for the perfect combination of challenging, rewarding, and remotely attainable. You fretted over every last little detail of your resume and cover letter. You spent countless hours brushing up on algorithms and data structures practice questions, determined to be prepared for anything they might throw at you in a technical interview. You made it through round after round of phone screenings, technical interviews, cultural interviews, and executive interviews. Finally, seemingly against all odds, they offered you the job and you quickly accepted before they could change their minds. Congratulations! …
Prismatic is an integration platform used by B2B software companies to build reusable integration workflows and deploy customer-specific instances that handle each customer’s unique configuration and credentials.
When we set out to create Prismatic, it was clear that we needed an API for our web app and CLI to use. Additionally, we wanted our developer users to be able to hit our API programmatically so they could manage customers and integrations as they saw fit. This presented a problem: different developers would naturally have different needs and use cases, and it didn’t make sense to craft a series of custom RESTful endpoints for each individual’s needs. GraphQL was growing in popularity (for good reason!) …
