Three ways for devops to overcome delivery and scalabilty issues

In one of my previous posts I asked the question; is your marketing designed for change? As software development is changing at an even faster pace and every company is quickly turning into a tech company, now it is time to ask your development team the same question.

Technology is outsmarting us in every way. Instead of resisting to this, we should embrace it.

devops-microservices-continuousdelivery
The 3 ways for devops to overcome delivery and scalability issues

Traditional software development practices have proven to be too inflexible and not scalable enough to be maintained. Will IT departments be able to evolve and take their game to the next level by becoming more agile and better-performing by overcoming the issues of:

1: Long term planning

2: Software scalability and delivery

3: Development and operations alignment

In this article we address these three issues and discuss solutions to take software development to the next level.

Issue 1: Planning for the future is impossible

Influenced by the development process of hardware, software used to be developed in what is called the Waterfall methodology; all development phases neatly flow into each other. The downside is that everything needs to be planned and making changes afterwards is very costly. The pace of the market demands a faster and more flexible development process.

Agile development
Agile development

Solution 1: Agile development

New software versions used to be released infrequently (monthly preferred over weekly) and always have been hair-rising exercises for the deployment team. “Will it work?” was the big question, and a sigh of relief the response after a release well-done. The popular way of development, building a monolithic application, has proven to be inadequate to deliver releases continuously as any change impacted the rest of the system immediately.

Over the past years, a more agile approach has been introduced, most commonly referred to as Scrum. When the current priorities have been set during a Sprint meeting, projects are divided, due to be finished before the end of the sprint. The abbreviation YAGNI (You are not going to need it) is often used, to point out that you only should do the things that are needed now and not think about what might become important in the future.

Although Scrum leads to shorter development cycles and more control, it is not the sole answer to continuous delivery. In order to be able to deploy applications in an agile and scalable way whilst guaranteeing continuous delivery, software architecture and development is changing as well.

Issue 2: One-size fits all is not such a good idea

Initially, software developers took the world on their shoulders by aiming to develop one big application (frontend, database and server-side application) in a single giant code base. This approach worked really well, until the limits of this approach were reached.

Multilayered architecture

When the traditional approach to software development of developing  reached its limits, developers moved to a multilayered architecture. A multilayered architecture often consists of a framework, object model, user interface and webservices on top of a database technology and one development language.

A few years ago, the limits of multilayered architecture started to show; software load exploded due to the increased amount of users and increased amount of data stored in the system, causing performance issues. Scalability of the product had to be pushed to the limits and adding new features nearly became impossible.

The increased complexity of releasing software

By this time, software improvements and bug fixing had become treacherous. Changing and releasing code in a live system, built from fully interconnected code, is one helluvajob. Imaging changing the wheels of a train that is moving forward at an ever-increasing speed.

Moving an application that is being pushed to its limits (one big platform, shaky performance due to amount of users and data) to an agile and scalable environment is challenging. Any code change directly impacts other, connected, parts of the software.

Continuous delivery
Continuous delivery

Solution 2: Continous delivery

From a release-based deployment approach in one big application, we are now moving to a situation where software is being released continuously. Application building blocks called microservices are combined to create apps. Delivery and scalability is standardized by using containers to build and run these microservices. Because of this standardization, generic infrastructures become available in the form of application platforms as a service (apaas).

Microservices

A microservice is a set of code, that can be run (and updated) independently from other microservices. Microservices can be combined to form applications.

Building software based on suites of small services offers major advantages over the traditional approach. Microservices e.g.

  1. Can run independently
  2. Are easily deployable
  3. Are scalable
  4. Can be developed in any language (so you can pick the best language and technology for the job
  5. Can be build using any technology, so you can use the right technology for the purpose
  6. Can be developed by different teams
  7. Can be changed and upgraded without the need to change other parts of the software

Transporting smart output to dumb end-points

The smart end-points and dumb pipes approach is most popular amongst developers. This is how it works: A microservice mostly works as a filter when receiving requests, applying logic and producing a response. So a request is sent to a microservice, that then handles it with the programmed logic and provides an output which can be used in other microservices.

The data transportation of the smart output typically is done by message routers, like RabbitMQ and ZeroMQ.

Containers

Software deployment is like shipping goods from A to B. Think of it: Products come in any sizes and shape, moving coffee beans around is very different to moving a piano. In order to be able to make shipment efficient, the way that products are being shipped has been standardized by introducing containers. Anyone involved in the shipping process knows how to label, lock, close and handle a container.

As microservices can come in any shape and size as well, the same methodology has been applied to software deployment using microservices too. A container in software development contains the code and everything else that is necessary to run the service on any environment, being a PC, MAC or Unix OS, Server or Virtual Machine. So not only this has a positive impact on software development, but because of the standardization, also on system administration and software releases. By using containers you are able to do hundreds of releases per day without impacting the rest of the application. An example of a company using containers in order to deliver the platform continuously is Spotify [Presentation]. The platform used by Spotify to ship, build and run their apps is called Docker

Application platform as a service (apaas)

In the slipstream of microservices and containers, we see a development in the area of infrastructure as well. Because of the standardization and the fact that a container consists of every element needed to deploy the service, traditional infrastructures using virtual machines are quickly becoming replaced by Application Platforms as a Service, cloud services that offer development and deployment environments for application services without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app. An example of a company using Docker’s platform to build, ship and run their apps in combination with aPaas is Baidu, the primary Chinese search engine. [CASE]

Advantages of APAAS as compared to Virtual machines are:

  1. Maximum load on CPU
  2. No need for big data centers
  3. Energy consumption can be cut in half, resulting in major cost savings
  4. No big image files to add extra nodes, but only small files that can run anywhere
  5. Starting up a machine using a container takes a couple of seconds (using images can take up to ten minutes)

Issue 3: Lack of R&D and Operations alignment

Traditionally, R&D (where software is developed) and Operations (where software is maintained and performance monitored) operate independently. When new releases have been deployed, it is Operations who needs to maintain R&D’s code. So it is Operations responsibility to make sure that the system works properly with the newly added code. If R&D is not too committed to writing clean and bug-free code, there is a huge negative impact on the relationship between development and operations.

In this way, IT will never be able to fulfill the demands of sales, marketing and the market in general.

The traditional approach of developing software to design one big application and bolt features on top of it, has proven to be not future-proof. The increasing amount of data and increased speed of change, require an agile approach with a focus on continuous delivery.

Moving from project to product management
Moving from project to product management

Solution 3: Moving from project to product management

Microservices are equal to miniature products. These products need to be reusable, easy to deploy and maintain. Development is not done in silo’s as it used to be, with a team focusing on only front-end, database or back end. No, developing microservices requires development teams to consist of multiple backgrounds and comes with responsibility. Because a microservice is not a project but a product, it does not end after the service has been released. The project team itself is responsible for the whole process of developing and maintaining the product, eliminating frustration between Development and Operations and aligning them.

BUILD IT / RUN IT

The biggest enterprises have been primal in the push forward of new development approaches. Amazon e.g. has introduced the build it / run it principle, where developers can no longer throw a finished project over the hedge to an operations team. When the shit hits the fan, it is their phone ringing in the middle of the night. This is a shift that is not only taking place for microservices, but affects software development in general. Because of the increased sense of responsibility and ownership, the efficiency of the product development process often increases.

End notes

The traditional software development approach reached its limits of scale, which lead to friction between development and operations departments, performance issues and release headaches. With the introduction of continuous delivery, microservices, containers, application platforms as a service and a product management approach, the challenges of scalability and continuity seem to have been overcome. This only adds to the already awesome opportunities of software development and internet technology, making it our future.

How is your Dev/Ops department impacted by these developments?

About Walter van der Scheer

Passionate about e-business and marketing technology, Walter strongly believes that every company should have a focus on agility and technology, acting as a tech start-up. Follow Walter on Twitter (@wvanderscheer), Linkedin and Google+.

Add a Comment

Your email address will not be published. Required fields are marked *

Quick IQ test to separate humans from computers... *