A while back, we introduced you to Amazon Web Services (AWS) for non-technical folks and today we’re continuing the discussion with the AWS cloud based Relational Database Service (RDS). Understanding the basic components of AWS like EC2 and RDS are some of the foundation blocks for most software, including mobile applications. Gaining high level knowledge in these areas can help, whether you’re a new engineer, manager or startup founder. And today’s topic is super important. Why? Because a database typically houses the most important information about your product, customers and business.

A database is at its most basic, a repository for information. With a large software product, you might have multiple databases, but for today we’re going to focus on a single database since most companies start with one. A database could be compared to a fancy spreadsheet.  Instead of tabs like in Microsoft Excel you might have tables and each table contains different bits of information. The way the information in the tables is laid out is called the data model. This is incredibly important as a software product scales because poorly structured data can be a pain in the you know what later on. So it’s not quite as simple as Excel.

The database for your application needs somewhere to live (like AWS or other cloud providers) and an engine that runs it (like Microsoft SQL Server, PostgreSQL, MySQL, Oracle, etc).  For most of our clients, we use AWS and PostgreSQL. In AWS we have a few hosting options, one is that we could spin up an EC2 instance and install PostgreSQL on that instance and then go from there. However, when we do that, we need to worry about making sure it’s highly available (always up), backed up (disaster recovery) and updated (latest version). If that single EC2 instance were to stop working, then we lose access to our data…and with most applications, that’s not a good thing.

That’s why Amazon introduced the Relational Database Service (RDS). RDS is not a specific type of database or database engine. It’s a managed service running in the AWS cloud for databases that is easy to set up, deploy, scale and update a database with the click of the button. No need to worry about high availability or keeping the database versions up to date. RDS will take care of it for you. Need to have everything backed up? No problem, it’s built in to RDS. Instead of building out everything necessary to have a highly available, durable and updated database, it’s already built into RDS.

On the cost front, RDS can look expensive but consider most companies would need to employ a dedicated person to setup and manage the infrastructure. And instead of days to setup a database, it took a few minutes. That’s time to be used elsewhere. RDS has simplified an incredibly complex process and should be considered as part of any scalable software infrastructure.

We’ve covered what a database is, why it’s important and why you should consider RDS as an easy way to setup a highly reliable database running in the AWS cloud. If you have any questions about how this might fit into your project, send us a note.

Amazon recently announced over 100 new cloud services and products at the latest re:Invent conference. While there are tons to be excited about, there are four cloud services that we look forward to using in future projects. Most we’ve had to build from scratch at some point or have had clients ask for them only to be disappointed in the high cost of development. All four services introduce easier ways to integrate machine learning into your cloud based software or mobile application, without significant added cost.

Amazon Personalize

When shopping on, have you noticed the recommendations based on your latest purchases? That’s all created by a recommendation engine that is based on things you like, and things other people like you have purchased too. Amazon is now making similar recommendation models available to developers. Imagine you have an app, like CurEat, that curates local restaurants and lists.  You can now make more personalized recommendations using Amazon Personalize instead of developing something from the ground up.

Amazon Forecast

Remember using spreadsheets to forecast sales for your company, or maybe for a school project? Ok, so maybe not everyone had to do that, but at some point in your career you’ve likely been asked to forecast sales, inventory, or some sort of business or application metric. With Amazon Forecast, you can now feed your data into deep learning algorithms based on the same algorithms Amazon uses for their own business. Amazon says their forecasts are 50% more accurate and are completely automated. Say goodbye to continuous feeding and care of spreadsheets for forecasts. As developers, we can use Amazon Forecast in all sorts of features and components, from predicting product usage to in app features like forecasting production material needs or equipment breakdown in IoT devices.

Amazon Textract

Amazon Textract is like an OCR service except it goes a few steps further and can extract data from fields and tables, and do so very affordably. This is great news for startups or really any company needing to integrate some level of OCR into their product. Imagine quickly building a mobile app that scans old school paper copies of insurance claims, medical records or any paper form. Then taking that data and uploading to a CRM or EHR system, quickly and easily. That’s just the beginning of what’s possible with Textract and there are sure to be more complex, more exciting uses for something that is now incredibly inexpensive and accessible. How inexpensive? Try $1.50 per 1,000 pages for the Document Text API. Read more here.

Amazon Comprehend Medical

Finally, for our medical device and healthcare clients, we’re super excited to see Amazon Comprehend Medical, an expansion of Amazon Comprehend. Amazon Comprehend Medical uses Natural Language Processing to process text in documents and files. Say you have years of medical records that weren’t exactly filed away correctly. Now you can use Amazon Comprehend Medical to process those files and look for patterns. For example, maybe you have an archive of unstructured documents, like physician notes, and you want to extract documents pertaining to a particular medical condition. You can use Amazon Comprehend Medical to look for the medical terminology that coincides with that condition, making it possible to comb through archives in a matter of minutes without manual intervention. It also has the ability to detect Protected Health Information (PHI) which could be used for organizing data or in some cases, avoiding parts of data that may not be necessary for a specific use case.

These are just four of the new services that will be available via AWS in the next few months, and we’re excited to help our clients introduce new features that are now more affordable than ever. If you’d like to hear more about what AWS can offer, contact us or read all the latest announcements from re:Invent here.

Relational Database Service

Today we’re kicking off a series that will tackle the basics of the Cloud – specifically Amazon Cloud. At this point, most everyone knows about the Cloud, but you may not know some of the basics, especially in regards to Amazon Web Services (AWS). The goal is to break down some of the most popular components of AWS in hopes that it becomes less overwhelming, aids in risk management and gives you a more solid understanding of what it means when your software application is running in the Cloud.

What is the “Cloud”?

The Cloud is any publicly available on-demand infrastructure or computing resource. On-demand is key. As an example, Amazon, one of the most well known technology companies around, offers a service called Amazon Web Services (AWS). For this conversation, I’ll focus on AWS terminology. Why? Because as of Q1 2018, Amazon still leads overall market share among cloud providers with Microsoft, showing strong growth but still far behind.

API & Elastic Compute Cloud (EC2)

Before we go any further, it’s helpful to understand a tiny bit about how cloud based software applications work. In our API 101 article, we mention that your phone makes contact with the Cloud via an API, which is pretty much just a URL that does fancy stuff. All of the work and logic that happens behind the API is hosted on a cloud service provider like AWS, typically using Elastic Compute Cloud (EC2) as the foundation.

As a systems engineer, I worked at several Software as a Service (SaaS) companies and we hosted all of our software in data centers. A data center is often a really huge building that contains a ton of computers, also known as servers. Anytime we wanted to expand or scale our software application we would buy more servers and rack them in the data center. There was much joy in the unboxing of new servers. That new hardware smell…like a new car. One of my teammates was even known to sniff the new servers, that’s right…you know who you are.

Sorry, back to the story. With AWS, a physical server equivalent is an Elastic Compute Cloud (EC2) instance. No need to purchase hardware, cable it and pay for power and location at a data center anymore – simply go to the AWS Console and create one on the fly. You may hear the term virtual machine or virtual server. An EC2 instance is Amazon’s version of a virtual server. A physical server, like those in the picture above, host several virtual servers. At a super high level, they’re basically special files that behave very much like a traditional server, except you can orchestrate these files, move them around to different physical servers, copy them, delete them and much more. Instead of looking at racks of servers, you login to the AWS Console, go to EC2 and have instances running like the one below:

Once an EC2 instance is setup and available, it operates very much like a physical server. You can login to the server, install software packages, reboot, shutdown and so on, just like a normal computer. For more scalable infrastructures, which is a topic for another day, we can take advantage of things like auto-scaling groups and other automation options that don’t require someone to login.

Amazon also provides a wide variety of services that make up Amazon’s total cloud service offering, “the AWS Cloud.” So when someone says they’re in the Cloud (with Amazon), they really have the software infrastructure hosted within one of Amazon’s massive data centers on Amazon physical servers. The same concept applies to Google Cloud and Microsoft Azure and several other cloud providers. It gets complicated because the terminology changes among the providers, as well as how they each approach their service offerings.

Understanding the basics can help you avoid any major issues down the road as your software architecture gets more complicated. Stay tuned to learn about Amazon Relational Database Service (RDS), in our next exciting post about AWS Cloud 101!


It’s a three letter acronym that’s thrown around all the time, yet most non-technical founders and businesses gloss over the impact of an API, the value it can add to your business, and how it can help you in the future. We’ll start by covering what an API is and how it works.

What is an API?

API stands for application programming interface, and most explanations on the web want to explain a whole bunch of other things like clients, servers, JSON, etc. We won’t go into that for this article because often times it’s kind of boring for folks that don’t work with it everyday.

You probably have a ton of apps on your phone, so for this scenario let’s use Google Maps. When you open Google Maps and search for “grocery”, the app needs to get that information from somewhere.

While most new phones have a ton of processing power, the amount of data behind something like Google Maps is huge. Since your phone can’t handle all of the data for every possible thing people search for, the data needs to live somewhere else. Additionally, when Google needs to change or update the search results, they don’t want to push constant updates to your phone. So it makes sense for all that data, and all the processing, to sit and take place somewhere else. Usually this is in the cloud, often a service like Amazon Web Services, Google Cloud, Microsoft Azure, etc.

OK, so we know your phone needs to contact the cloud for some information but how does it know which cloud, where in that cloud and what info to get? That’s all a part of the API! The API has a URL just like any other web page. Therefore, when you search for “grocery” in Google Maps, your phone hits that URL in a special way and automagically serves up specific information about grocery stores to your phone.

As one of my former economics professors used to say in class, “So What?” The phone talks to a server (aka the cloud) and the server returns some information that the phone not-so-magically understands, how does that really help?

What does that mean for you or your project?

It means that your project’s API (the thing that magically serves up content so the app on the phone can operate) needs to be super well documented, well laid out and secure. It also means that time and attention should be devoted to correctly building it out. The API is basically a map for the app on your phone. If you also have a web app that matches, it will use the same API. If the API is poorly documented, you can expect some real problems both during development and afterward – making troubleshooting or sharing information a nightmare.

What does this have to do with business?

A large number of companies sell the data behind an API to other parties. Google, again, is a prime example. As developers, we use the Google Maps API quite a bit.

As a business you may not be thinking about selling the data, but what if you have integration partners down the road? For example if you’re building a CRM, what if people want to sync data between their app and yours? Or if you have a product in the healthcare space, maybe you’ll need to integrate with Epic at some point. You’ll need to not only understand your API but understand their API in order to be successful.

Other examples include the Facebook Graph API and Twitter APIs.  Both are open to developers to use for new apps. ProgrammableWeb has an online directory of APIs that are both free and paid. It’s worth a little searching if you’re building an app to see if you can buy versus build from scratch.

The API market itself is continuing to grow, including tools and servers around APIs. Take a look at two major acquisitions by Oracle and Google for API design, documentation tools and management services.

If you’re building an app, definitely consider the market potential for the API. Often, there is more long term viability behind the data and what others can do with the data versus the actual app.