RedHat Summit 2016 opening plenary started with a powerful message delivered by Jim Whitehurst, Red Hat’s president and CEO : helping communities innovate beyond the sum of their individual members is the leadership challenge of our time.
The speech focused on the 4th industrial revolution that is happening right now : billions of people and devices connected, unlimited access to knowledge, AI breakthroughs, 3D printing, all helping innovation happen at a greater than ever speed.
Our abilityto harness and distill the best ideas will determine human progress for the next century and open communities are in a unique position to drive this innovation : the next developments are too big even for the largest corporations to address alone. Companies are realizing there is more value in opening their platforms and creating ecosystems than staying closed and building systems.
A couple of weeks before the event I started scheduling the sessions that I would like to attend and decided to focus on three areas : open source communities development, devops and mobile.
Open source communities
Working with an open source project and delivering an enterprise product based on it poses some challenges to vendors.
How do we distribute changes ?
Some vendors maintain differentiation by developing features in private, and integrating them in their products, eventually integrating them into the upstream open source projects (if ever). Others will integrate changes at the same time as they are released in a product.
RedHat’s policy is “upstream first” – features are integrated into open source projects before integrating them into its product offerings.
The arguments for upstream patching are that it saves time and money and keeps communities alive.
How do we keep the projects alive ?
One of the best ways is to hire developers and involve them in the upstream open source projects. This signals involvement from the company and that the project will not be abandoned.
How do we keep everyone in touch ?
There are many aspects and departments involved in keeping an enterprise product and the upstream project running. Making sure everyone understands the business model and changes are communicated throughout the ecosystem is required, or it could potentially destroy the company if legal issues arise.
There are different resources available for everyone :
⁃ For management: open source events
⁃ For developers: linuxfests, devops days, meetups, local events
⁃ For legal: legal networks, scale, fosdem, linuxcon
DevOps – we’re not IT anymore, we’re part of business
DevOps is an approach to culture, automation, and platform design aimed to increase the speed and flexibility of delivering new products or services.
Every department has its own tools that automate its processes – Jenkins for continuous integration used by developers, scripts or configuration management apps for operations, unit test frameworks used by QA or communication tools used by everyone. DevOps aims to automate as much as possible from code to deployment on production servers, so companies can focus on what’s important : creating business value.
It all starts with a company culture centered on collaboration and openness. Lines that separate traditional departments in a software development company (devs, infrastructure, QA) are blurred, communication is encouraged and tools are shared.
Automation is the key to accelerate application delivery. Everything that can be automatized should be, with focus on what takes the most time.
In order to enable automation for all departments, a set of dynamic, programmable tools is required.
RedHat offers Ansible as a simple, powerful, agentless platform for automation. It uses an automation language that is accessible to non developers and is quick to learn.
Everything from continuous integration, deployment, provisioning, managing systems or communication can be described and automatised in Ansible.
Ansible Tower is an enterprise feature developed by Redhat to provide a simple dashboard, a restful API and role based access control for Ansible.
An approach to implementing DevOps starts with asking the right questions:
– What can we automate and in what order ?
– What is taking the most time in the delivery process ?
– Do individuals understand the value of their contribution to the business ?
– What is the effort and the impact of every contribution ?
– How happy are the developers ?
– How can we reduce technical debt ?
Mobile
Increasing the speed of delivering new features requires new paradigms in application architecture : shifting from a monolithic tiered approach to a cloud based, microservices architecture.
Mobile is not a new domain, but maturity brings new challenges: multiple versions of your backend API running in parallel, low latency requirements as your user base is expanding, memory constraints and so on.
Microservices are applications that address a small and independent set of business features. They communicate with a each other via “dumb pipes” – HTTP calls to REST APIs or fast lightweight messaging. They are independently deployable, so dependencies are easy to maintain and can run multiple versions at a time.
Microservices are also gaining ground because they require little to no effort for provisioning and can scale very well.
Developing a small set of independent functions enables rapid iterations and a more fluid way to define requirements and manage change. That is sometimes called agile development.
The last piece of the puzzle is DevOps. Almost everything about developing microservices can be automated, from continuous integration, testing, staging to deployment on production servers.
All these things are not new and can be dismissed as an overhyped trend (just don’t call it SOA 2.0), but the combination enables fast mobile application development.
Author: Horia Beschea, Software Development Director at Allevo