Why You Need to Keep Your Mobile DevOps In-House in 2018

Shashikant Jagtap

Believe it or not, setting up and managing DevOps tooling is a brainfucking activity. It’s true for both web and mobile application development. It requires the deep understanding of server and networking technologies, automation with complex scripting, cloud technologies and 24 x 7 Monitoring support. This became a cause for a headache for many entrepreneurs, 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. The DevOps activities became a white elephant in the web and mobile application development. The application developers don’t possess the skills to deal with DevOps toolings and having dedicated DevOps team is too expensive for business 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 BuddyBuild purchased by Apple at the start of 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 is ‘Nobody Knows” i.e there is no concrete definition of DevOps anywhere. There are various myths about DevOps. Some people say it’s set of tools, it’s new development methodology, it’s team that manages CI/CD, it’s jobs title or role but none of them is true. The way I understand DevOps is very simple, take it or throw it but  my definition of DevOps is

“Whatever fuck you do to speed up releases of  bug free software is considered as DevOps”

DevOps is vast, there are millions of blog posts, thousands of white papers, hundreds of books and there is 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”, OMG such a long name but it has 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 i.e System Thinking, Amplifying Feedback loop, Continual experiment & Learning.

Mobile DevOps vs Web DevOps

Developing the websites and mobiles apps are two completely different set of 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 toolings used for web and mobile are also different. The techniques and processes can be 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

The 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 apps various environmental target. 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 AppStore or Play Store once they have been released however web applications need hosted servers either in the data centre or cloud. Today most of the 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 AppStore or PlayStore will take care of hosting.

  • Pull Vs Push Deployments

Web applications always have push deployments means a new version of website deployed on demand and users don’t have the 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 case of releases mobile apps. Another thing is there are no continuous deployments in the mobile world as Apple or Google has to approve an app before releasing which is a couple of days wait before the new version of application goes live. Mobile application releases are very risky than the web applications.

  • Technologies

There are major differences in the tools and technologies for developing web and mobile applications. The programming languages used for mobile native developments are Swift, Objective-C in case of iOS and Java or Kotlin for Android. There are some other hybrid frameworks available for developing web and mobile together. However, web applications can be developed using millions of programming languages like Java, Ruby, PHP, Python, JavaScript etc. The tools for Continuous Integration also differ a lot for the platform to platform. e.g Jenkins is a very popular tool to deploy web applications to everywhere however it doesn’t always a good choice for mobile continuous integration.

  • Backend Services

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 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 of the companies, the mobile DevOps activities are either handled by cloud continuous integration services or handled by different companies or departments within the same company. Let’s focus on what are those activities and why they are always cloudified (not sure this is an English 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 one.

  • Setting up and managing build server for Continuous Integration
  • Automating builds using build tools
  • Managing Scripting Code Signing activities with correct provisioning profiles, configuration and certificates ( for iOS)
  • Setting up Continuous Delivery Pipeline with automated build phases
  • Making sure fast and unambiguous builds execution
  • Monitoring application using various tools

These activities are time-consuming, hard and requires special skills on top of application development skills. The important thing is these activities are often considered as secondary activities. The businesses conder that they don’t earn money by investing in those activities, they find it hard to get buying to do these things.

There 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 team spend a lot of time fixing CI issues.
  • The application developers are interested in Mobile DevOps activities but business can’t get buying to do these activities.
  • Lack of required hardware infrastructures to setup Mobile DevOps practices in-house
  • 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 the most of the DevOps tasks. The cloud-based CI servers have some pros and cons as well.

Pros

  • Easy Setup
  • Less scripting as cloud-based CI services has 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 setup build servers
  • Streamlined cost and improve development resource utilization
  • Easy to learn

Cons

  • Cloud-based CI services charge lot of money to run your builds. They are not cheap.
  • Recurring Cost. You will have the huge bill ready monthly or annually.
  • You can not control build setup from code in most of the cases.
  • You can not run tests on real devices.
  • Cloud-based VMs are so slow that running UI tests are nightmare
  • You have given permission of your code, certificates and everything to third party CI services.
  • You can not get updated from 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 ran
  • Hard to store logs of the builds as VM’s got killed after every build
  • Imagine your cloud-based CI provider went down on the 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 that covert the cloud-based pros as self-hosted cons and vice versa but we will put it in a different way

Pros

  • No recurring cost. We can save 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 can flexibility to install tools soon as releases by Apple or Google( even beta versions)
  • No need to share your code or distribution certificates outside of the organisation. 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.

Cons

  • 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 resource for managing servers.

Why Choose Self-Hosted Solutions

Now that, we have seen the pros and cons of both self-hosted, as well as cloud-based CI, provides to manage Mobile DevOps activities. It’s time to make a decision what to choose self-hosted or cloud-based? The short answer is “It depends” and I hate this answer. I usually hear this answer from the conference speaker for the tough question. Remeber this whenever someone answering saying “It depends” it means that guy is totally confused and don’t know the real answer. Anyway, but 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 top reasons

  • Save Money

You might be wondering how we can save money by In-House DevOps? Its hard at the start but once the team got a grip on DevOps tools then it would be much cheaper in long run. Companies building mobile applications have to buy devices for testing purpose anyways and buying another piece of hardware won’t be big deal. I think its much cheaper than paying the 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 have to go for the self-hosted solution.

  • Save Time

The builds in the cloud are very slow. It requires booting new VM, installs dependencies, software packages, prepares keychain, import certificates, checks out source code etc. We have to repeat the same for every build. It adds additional few minutes for every build. With self-hosted solution with good internet speed, we can save many hours per day. The 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 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 last beta tools and real device testing with a self-hosted solution. We can try and experiment new things on our own servers. You should be able to define and manage build configuration and whenever things go wrong then you know the ropes. We can fix it easily or rebuild entire server. In case of cloud, if something goes wrong then you spend days to fix issues which might turn out the problem with your cloud provider. You might need to their support team take 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 have to deal with priority for any organisation. If you are big established company and would like to hand over your sensitive data to outsourcing company or cloud-based providers. Not all the time but there is potential risk always there. Can you imagine a situation that 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 e.g  BuddyBuild

If you heard the news at the start if the new year that Apple buys BuddyBuild, which might have affected many Android users of buddyBuild. Now, they will be removing Android support with 2 months of notice. As a result, many Android teams might be looking for another option XYZ. What if XYZ got sold tomorrow, you should be hopping between the cloud-providers. Instead be smart and build your own regime.

Tips for In-House Mobile DevOps

Some tips that you can use to successfully implement In-House Mobile DevOps within a mobile team.

  • There are various options for self-hosted CI solutions to other DevOps tools. Make sure you select the right one that suits your team. Use natives 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 to train engineers.
  • Hire engineers who have basic knowledge of Continuous Integration and DevOps. Having 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 A Code is the key to successful configuration management. Avoid manual configurations on CI server.
  • Get a quick and reliable server for Continuous Integration; avoid cheap servers. Use the fast internet (ethernet) to speed up builds.
  • Promote the importance of DevOps practices within the management and explain the business values to them

Conclusion

2018 started with news that might be affected many Android users of BuddyBuild which was an indication to companies to think on 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 toolings 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.