I was able to wrap up the Summit “graveyard shift” the same way I began the week: Hanging out with the Red Hat Mobile folks. Love those guys.
This session was centered around MAD: microservices, agile, and DevOps. On top of that, Cian Clarke, John Frizelle, and Philip Hayes of Red Hat Mobile showed how all 3 of these pieces relate to Red Hat Mobile Application Platform.
Cian began talking about the new era of applications. Apps can’t cost hundreds of thousands of dollars anymore. They can’t take 6 months to develop; that’s far too long. They don’t live for decades–traditional software lasts for a long time.
“Now, the idea of an application living for 10 years is almost laughable.”
He then gave an example of a mobile app that was built for emergency flooding in the UK. It was built overnight, deployed, used to report problem areas, and then decommissioned once the emergency had passed. That’s perhaps an extreme example of how transient apps are becoming, but the point stands. Finally, apps can’t be big monoliths on the client side. They must be small apps, fit for purpose, and that do one task well. Cian the talked about the mobile center of excellence, a way for businesses to organize, manage, and deploy mobile solutions and initiatives.
Why you need a mobile center of excellence
You need in-house skills for this important delivery channel. Don’t think of this as corporate IT. Think of it as fast IT. Mobile is different–there are lots of small apps and fast update cycles. The reality of mobile means that the center of record has changed for mobile devices and if you build with that in mind, you’ve got a little backup system right in your pocket and the pockets of your users. Offline support also means back ends can fail. Those records still exist on mobile devices. These are just a few factors to take into account when moving in a more-mobile progression. A mobile center of excellence allows you to do this methodically and in a repeatable fashion.
The 3 pillars: microservices, agile, DevOps
The mobile way of developing apps is, in many ways, antithetical to the traditional approach. This is best summed up as:
|The traditional approach||The mobile way|
|Systems of record||Systems of engagement|
|Monolithic||Simple, nimble apps|
|Multifeatured||Highly targeted to need|
|Long dev cycle||Fast dev cycle|
|Infrequent, large updates||Continuous integration / continuous deployment (CI/CD)|
Updating mobile is different
Web apps (maybe) take hours to deploy. Once you deploy, your users see the latest and greatest. Mobile apps with a private app store take days. To deploy, you force the update and your users’ devices update. But, the public mobile app store can take days, if not longer. It’s no longer as fast to update because you’re uploading, waiting for review, then waiting (and hoping) for your users to update the app on their end.
Microservices help this. Have your mobile apps rely on microservices to handle the heavy lifting and features of updates. This way, you treat all of your mobile apps the same way that you’d approach web apps. Deploy in hours. Deploy when you want.
John covered the concepts of agile development. I’ll make an assumption about my audience here and skip the step-by-step of working in an agile environment. The basics are that you need to make a plan, size it up, set your priorities, get executing, and update the plan as you go.
Like any kind of methodology, there are terms specific to agile development, such as user stories, iterations, burndown charts, etc. You could argue that the important thing about agile development isn’t what it is, it’s what it isn’t.It’s not like the waterfall methology.
Things change in business and development. Being able to flex and reprioritize as these changes come up is of great importance. Your backlog of work, with frequent and small reviews guarantees that you’re able to keep moving forward without losing sight of what you’re trying to accomplish.
Gone are the days of massive, monolithic software that takes years to deploy. Deploy fast. Deploy often. Use agile to support that aspiration.
For more information about agile and the theory behind all of this, check out the agile manifesto.
DevOps, the unification of development and operations teams, flows directly out of the agile approach and extends that culture to tools. This builds on the process foundation of microservices. Philip Hayes took over from here and described the types of tools that you may typically find in a DevOps environment. Those can include:
- A continuous integration (CI) server
- Git-based supply chain management (SCM)
- Ansible, for IT automation
- Red Hat Mobile Application Platform
- CI server plugins
- Build tools
- Testing frameworks
- Command line tools
- External services
- Node package manager (NPM) modules, to manage the packaging of Node.js
Philip described the life cycle of a DevOps-based mobile business. Typically developers push to their git repository, which is picked up by the Jenkins pipeline, tested and then pushed to Red Hat Mobile Application Platform. The code is then built and deployed, assuming all tests and check have passed. This allows for quick iteration and constant deployment.
MAD + Red Hat Mobile Application Platform
Red Hat has built their mobile platform with the users in mind. No lock in–instead the focus here is on options. There are options to run the tools and processes that you want to run. Create your project the way you want. Deploy how you want. What’s more, Red Hat Mobile Application Platform provides unit and acceptance test best practices, life cycle management, health endpoints to tell ops teams of issues, cloud and Mobile Backend-as-a-Service (MBaaS) services.
Also included is access to buildfarms for your apps, such as Android and iOS. You can also manage binary deployments with mobile device management (MDM) integration.
“The mobile center of excellence is the most important strategy to bring about mobile success and achieve mobile zen.”