Given the prevalence of mobile apps, organizations need to ensure that their development process and the cloud infrastructure supporting the app are solid, secure and efficient. In this post, I will run you through some of the high points to consider as you roll out mobile applications.
To set the stage, I’ll harken back to the classic movie, “This is Spinal Tap,” where the fictitious band had an amplifier that “went to 11,” even though 10 is the maximum volume. It’s really an indication that everything having to do with mobile apps is super-sized.
Mobile apps that go viral and need to scale consume significant resources because when they hit big, they hit BIG. If the application has any kind of customer or protected data, you need to think about things like data protection across potentially millions of endpoints. Observability is also a key requirement to ensure the best digital experience and application performance.
Let’s not get ahead of ourselves though. I recommend you begin by thinking about the data flows of the application and building from there. If it’s a transactional application that requires data access from cloud data services or on-prem databases, you need to figure out how to do that securely with the proper latency characteristics.
Once you understand how the data needs to flow between the mobile device and the rest of the infrastructure, you can start planning the different pipelines that will control the development and deployment of the mobile app and the underlying cloud infrastructure.
What are the advantages of using pipelines and modern development techniques? You can super-size the velocity at which your development teams work. Here are a few to consider:
- APIs and associated microservices enable platform independence so that you can use (mostly) consistent code regardless of the mobile platform.
- Leveraging cloud platform data services provides simplified data integration, allowing the application to address the data service without worrying about the nuances of any underlying platforms.
- The automation inherent to CI/CD offers enhanced speed and flexibility in making changes, resulting in faster deployments.
Yet, these development approaches also super-size the attack surface of a mobile application. There is more data on more devices, with less control over the user base, which makes securing the environment critical. You’ll want to have plans for the following aspects of security:
- Application testing in the pipelines: You’ll want to make sure that the application undergoes static testing, software composition analysis and dynamic testing (where possible) before deploying the application.
- Configuration management and threat detection of the cloud infrastructure: Proper configuration of the cloud resources is a best practice to ensure attackers cannot utilize services like IAM or object storage to gain access to data.
- IAM to manage what could be millions of users: For mobile applications, the architecture needs to support potentially millions of users, ensuring their entitlements are set correctly and underlying resources are isolated.
- Incident response: Even with the best security, successful attacks happen, so it’s critical to understand how to identify, contain and remediate any potential attacks.
Finally, you’ll want to make sure you have a full view of everything happening within the application and that you’ve got solid operational motions to ensure the application is performant and resilient. Ensuring the application stack is instrumented and you are analyzing the telemetry via observability platforms is a critical first step. As the application platform matures, you’ll also want to start using SRE (site reliability engineering) practices to ensure the application scales and provides requisite availability.
I’ve only really scratched the surface of the considerations as you prepare to roll out a mobile cloud-based application. The best advice I can provide is to consider how massive scale and faster deployment cycles will impact the application and infrastructure from top to bottom. You don’t want to be in a position to have to work around a brittle infrastructure because you didn’t plan for usage to “go to 11.”