Why You Need to Keep Your Mobile DevOps In-House in 2018
Why You Need to Keep Your Mobile DevOps In-House in 2018
From a business standpoint, in-house DevOps might not seem to make sense. See why it's becoming essential for mobile app developers.
Join the DZone community and get the full member experience.Join For Free
Believe it or not, setting up and managing DevOps tooling is a time-consuming activity. It's true for both web and mobile application development. It requires a deep understanding of server and networking technologies, automation with complex scripting, cloud technologies, and 24/7 monitoring support. This became a headache for many entrepreneurs and project or program managers, to the point where many choose to outsource this process altogether to some other company or use cloud-based providers to deal with this. DevOps activities became a white elephant in the web and mobile application development. Application developers don't possess the skills to deal with DevOps tooling, and having a dedicated DevOps team is too expensive for businesses, as it doesn't generate business revenue directly. In this post, we will see why you badly need to consider in-house mobile DevOps in 2018. Yes, in 2018- because you might be affected by the BuddyBuild purchase by Apple at the start of the New Year. At the end of this post, hopefully, you will see some of the benefits of having in-house mobile DevOps
What Is DevOps?
So what the heck is DevOps? That's the million dollar question, and the short answer is "nobody knows," i.e. there is no concrete definition of DevOps anywhere. There are various myths about DevOps. Some people say it's a set of tools, it's a new development methodology, it's a team that manages CI/CD, it's a job title or role - but none of them is true. The way I understand DevOps is very simple; take it or leave it, but my definition of DevOps is "whatever stuff you do to speed up releases of bug-free software is considered DevOps."
DevOps is vast. There are millions of blog posts, thousands of white papers, hundreds of books, and a novel to explain the concepts of DevOps. There is a novel called "The Phoenix Project: A Novel about IT, DevOps and Helping Your Business Win." Such a long name, but it has the nuts and bolts of DevOps. I strongly recommend this to everyone who wants to understand DevOps in and out. There is no need follow predefined processes, techniques, or tools for DevOps practices, however, DevOps has three pillars mentioned in the novel that you should follow: System Thinking, Amplifying Feedback Loop, and Continual Experiment & Learning.
Mobile DevOps vs. Web DevOps
Developing websites and mobiles apps are two completely different activities. They differ in technologies, infrastructure, processes, tools, and skills, so it's hard to mix both things together. As a result, DevOps practices or tooling used for web and mobile are also different. The techniques and processes can be the same to manage both web and DevOps, but there are some major differences in tooling. We will cover the 5 basic differences here:
Browsers vs. Devices
Web applications have to support various desktop/mobile operating systems and browsers while mobile applications have to support platform-specific mobile operating system with multiple variants. Mobile has to support multiple variants, e.g., iOS has various of iOS versions on iPhone, iPhone+, and iPad variants.
App Store vs. Hosted Servers
Mobile applications are hosted on the App Store or Play Store once they have been released, however, web applications need hosted servers either in a data center or the cloud. Today, most web applications are hosted in the cloud like AWS, Azure, or similar. Web applications need operations and monitoring all the time, however, mobile apps don't need to monitor for hosting as the App Store or Play Store will take care of hosting.
Pull vs. Push Deployments
Web applications always have push deployments, meaning a new version of the website deployed on demand, and users don't have a choice to accept or reject updates. However, mobile applications have pull deployments, where users have the choice to update to a new version or not unless it's forced. There is no rollback in the case of releases for mobile apps. Another thing is that there are no continuous deployments in the mobile world, as Apple or Google has to approve an app before release, which is a couple of days' wait before the new version of the application goes live. Mobile application releases are very much more risky than web applications.
Unfortunately, it's not possible to put all the required data into the application, so both web and mobiles apps rely on some sort of backend services or API that provides data to them. The services may or may not be designed to serve both web and mobile, so its essential to find out any change in backend services that can affect either or both mobile or web app. There needs to be separate attention required for mobile apps as well.
Cloudification or Outsourcing Mobile DevOps
In most companies, the mobile DevOps activities are either handled by cloud continuous integration services or by different companies or departments within the same company. Let's focus on those activities and why they are always cloudified (not sure this is a real word) or outsourced. There might be millions of DevOps activities that we have to carry out apart from normal development activities, but we will cover the major ones:
- Setting up and managing a build server for Continuous Integration
- Automating builds using build tools
- Managing Scripting Code Signing activities with the correct provisioning profiles, configuration, and certificates (for iOS)
- Setting up a Continuous Delivery Pipeline with automated build phases
- Ensuring fast and unambiguous build execution
- Monitoring applications using various tools
These activities are time-consuming, hard, and require special skills on top of application development skills. The important thing is these activities are often considered secondary activities. The businesses think that since they don't earn money by investing in those activities, they find it hard to do these things.
These are some reasons the mobile DevOps activities are always handled by cloud-based providers or some other team:
- The application developers don't have skills to manage mobile DevOps activities within the team.
- The application developers wrote amateur scripts that keep breaking builds all the time and the team spent a lot of time fixing CI issues.
- The application developers are interested in mobile DevOps activities but business can't get funding to do these activities.
- Lack of required hardware infrastructures to setup mobile DevOps practices in-house.
- The business wants to focus on building mobile apps rather than spending money on secondary activities.
Pros and Cons of Cloud-Based CI Servers
Although companies are choosing cloud-based CI solutions for managing most DevOps tasks, cloud-based CI servers have some pros and cons as well:
- Easy setup
- Less scripting as cloud-based CI services have default configurations
- Flexible and scalable. Might have Parallelisation of builds if we pay more
- Complex code signing activities handled
- No need to have hardware to set up build servers
- Streamlined cost and improved development resource utilization
- Easy to learn
- Cloud-based CI services charge lot of money to run your builds. They are not cheap.
- Recurring cost. You will have a huge bill monthly or annually.
- You can not control build setup from the code in most cases.
- You can not run tests on real devices.
- Cloud-based VMs are so slow that running UI tests is a nightmare.
- You have given permissions for your code, certificates, and everything to third party CI services.
- You can not get updated by Apple or Google right away. You have to wait for them to update the VM to support new tools.
- Very less, almost no access to the VM on which your builds run.
- Hard to store logs of the builds as the VMs get killed after every build.
- Imagine your cloud-based CI provider went down on an important release day.
- Imagine your cloud-based provider got hacked. Think about your source code and certificates.
Pros and Cons of Self-Hosted CI Solutions
Here, we can simply say the cloud-based pros as self-hosted cons and vice versa, but we will put it in a different way:
- No recurring cost. We can save a huge amount of money if we have hardware.
- Full control of build machines. We can manage machines as per project needs instantly.
- Add or remove software as required. We have the flexibility to install tools as soon as releases by Apple or Google (even beta versions).
- No need to share your code or distribution certificates outside of the organization. You can achieve full privacy.
- Attach loads of real devices to the server to run your tests. Build your own device cloud.
- Store your build reports for the specified duration.
- Management overhead
- Huge learning curve for developers in order to learn DevOps tooling
- Need hardware to setup build servers, which can be costly
- Dedicated/allocated resourcea for managing servers
Why Choose Self-Hosted Solutions?
Now that we have seen the pros and cons both self-hosting and cloud-based CI provide to manage mobile DevOps activities, it's time to make a decision: self-hosted or cloud-based? The short answer is "it depends" and I hate this answer. I usually hear this answer from a conference speaker for the tough question. Remember this whenever someone answering saying "it depends:" it means that guy is totally confused and doesn't know the real answer. Anyway, my personal advice would be: if you have enough DevOps enthusiasm and skill, then you should definitely go for the self-hosted solution. Here are the top reasons:
You might be wondering how we can save money with in-house DevOps. It's hard at the start, but once the team has a grip on DevOps tools, then it will be much cheaper in the long run. Companies building mobile applications have to buy devices for testing purposes anyway, and buying another piece of hardware won't be a big deal. I think it's much cheaper than paying a huge bill every month. I am not going into the accounting details, but if you are thinking about a long-term project and long-term benefits, you must go for the self-hosted solution.
Builds in the cloud are very slow. It requires booting a new VM, installing dependencies, software packages, preparing a keychain, importing certificates, checking out source code, etc. We have to repeat this for every build. It adds an additional few minutes for every build. With a self-hosted solution with good internet speed, we can save many hours per day. Cloud CI gives inconsistent test results, especially for UI tests. You will end up spending more time investigating issues that were not the real issues.
Take Full Control
With a self-hosted DevOps solution, you have full flexibility to install any software or packages. You can code your entire build and infrastructure and use it anywhere on any machine using configuration management tools. We can benefit from beta tools and real device testing with a self-hosted solution. We can try and experiment with new things on our own servers. You should be able to define and manage build configurations, and whenever things go wrong, then you know the ropes. We can fix it easily or rebuild the entire server. In case of the cloud, if something goes wrong, then you spend days fixing issues which might turn out to be a problem with your cloud provider. You might need to their support team to help to fix your build issues. Why should you go to someone else to fix the problems of software that you are building? You should create your own destiny.
Privacy and Security
Privacy and security should be a priority for any organization. If you are a big, established company and would like to hand over your sensitive data to an outsourcing company or cloud-based providers, there is always potential risk there. Can you imagine a situation where your startup cloud-based provider got hacked? Who will be responsible for that loss? You got my point, right? Let's move on.
Learn From Lessons Like BuddyBuild
You may have heard the news at the start of the new year, Apple bought BuddyBuild, which might have affected many Android users of BuddyBuild. Now, they will be removing Android support with two months of notice. As a result, many Android teams might be looking for another option - XYZ. What if XYZ got sold tomorrow? You would be hopping between cloud-providers. Instead, be smart and build your own regime.
Tips for In-House Mobile DevOps
Here are some tips that you can use to successfully implement in-house mobile DevOps within a mobile team:
- There are various options, from self-hosted CI solutions to other DevOps tools. Make sure you select the right one that suits your team. Use native CI tools from Apple or Google rather than third-party ones.
- Ask your team about their past experiences and select the tools accordingly so that there will be less hassle when training engineers.
- Hire engineers who have basic knowledge of Continuous Integration and DevOps. Having the experience of developing apps is not enough these days.
- Hire experts on short-term contracts to set up the CI process and share knowledge.
- Take control of build configuration by putting the config file, bash script, or similar file inside the source code. Infrastructure as Code is the key to successful configuration management. Avoid manual configurations on a CI server.
- Get a quick and reliable server for Continuous Integration; avoid cheap servers. Use fast internet (ethernet) to speed up builds.
- Promote the importance of DevOps practices within management and explain the business values to them.
2018 started with news that might affect many Android users of BuddyBuild, which was an indication to companies to think about their mobile DevOps strategies. Having self-hosted in-house solution is always better for mobile app development, rather than third-party services. You might struggle at the start to learn DevOps tooling, but it will have some great long-term benefits. What do you think about self-hosted solutions? Share your ideas or swear at me in the comments below.
Opinions expressed by DZone contributors are their own.