When developing Mobile Apps, and web apps, we would like to deliver a balance of performance, security, and maintainability. In our experience, the hardest problem with maintaining code or updating is the lack of documentation and deployment. Manually launched servers could be running Apache, Nginx, multiple databases, handle multiple domains. We want to design apps so that we can “pass the keys”. Apps designed so that they’re as easy as possible for onboarding developers, but also as easy possible for us to manage the separate components of the app.

Going Serverless (mostly)

Going serverless may require a bit more administration up front, but the idea is that everything is production ready. It is our goal to deliver something that can be modified and augmented with as little as a headache as possible. Separation of services allows for greater bandwidth control and even throttling.

Serverless Components

User Authentication: In order to manage our users, authenticate logins, we are using AWS Cognito, however, there are a number of similar services that offer the same benefits. Key benefits, User Accounts are handled separately by 3rd party service.

Key Benefits:

1. Built-in email verification, using Amazon’s servers, this eliminates the need to run an additional email server specifically for email verification.
2. Those emails are less likely to be marked as spam
3. As additional features are added, such as a web version of the app, there is less risk for conflicts, as the same log in pattern can be reused.
4. Built in user management tools. Rather than SSH Tunneling into a SQL DB, or a MongoDB and then running scripts or using DB tools to manage databases. The user management tools provided by Cognito, or another Identity provider are engineered specifically for User Management.

Frequent (faster) Access Data Storage: This level of storage is appropriate for documents/values that the App will need to access frequently. On a server this would be a NOSQL DB or a SQL DB. We are using Dynamodb.
Key Benefits:
1. Data analysis tools, the ability to hone in on what’s being used and how often.
2. Data Backups, ability to schedule back-ups.
3. The pay for what you use model allow for fine tuned control of throughput.

Long Term Storage/Large Object Storage: This storage is appropriate for larger files, media, back-ups. AWS version of this is AWS S3. Key Benefits:

1. Separate from the server.
2. Built in data redundancy.
3. Transparency and organization of data.
4. Integration with other AWS services.

Still need server: Can still use a server to perform certain tasks (if applicable). In case we need to run a server to perform tasks. Image manipulation could require dedicated server space. The needs of the application can be evaluated, considering costs, scalability, and performance. If scalability is large concern AWS beanstalk offers EC2 resource management tools.

Big drawbacks of serverless approach.
1. Vendor lock-in, using AWS’s SDK, Lambda functions would probably be the biggest area of concern. Transferring resources to another provider could prove to be more difficult.
2. Learning curve, with each service there are specific access rules, and frameworks that need to be managed, and this requires some proprietary knowledge of the platform.

Conclusion:

I think it’s important to remember the WHY of adopting this approach. We want to deliver products that are functional at high volumes, affordable, and we want to do it fast. When it comes time to go to production, we want to know what the limitations of the app are. We want it be transparent to the client what they are paying for. We want to know that user information is kept secure. With all these services, I think it is important to remember that we can always fall back on traditional (virtual) servers if we aren’t happy. In the end we just want to make high quality apps.

Key Metrics: Time to market (coding/configuration time), expenses of services, Maintenance (including manual scaling, more coding/configurations).