Essential guide to optimising hybrid IT infrastructure
A comprehensive collection of articles, videos and more, hand-picked by our editors
Customer relationship management (CRM) and enterprise resource planning (ERP) are enterprise applications that were created to do a specific set of tasks that an organisation needed.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Trouble is, these nominally single-purpose applications have grown until they bear no relationship to what they once were, and the way in which they attempt to create an “own and control” environment no longer fits with businesses that are trying to compete in increasingly dynamic and complex markets.
Now, the world has started to look at dynamic composite applications. Rather than try to chase a single application that does everything, the search is now on for a way to create functional stubs that can be brought together in real time to support a business process at a specific time.
Intelligent FAQ system
Let’s take an example: a simple means of a prospect becoming a customer, ordering an item and paying for it. Even now, a lot of the technology that underpins this could well be being served via third-party services.
Questions that the prospect has in mind may be responded to by Transversal’s intelligent FAQ (frequently asked questions) system; the payment is unlikely to be gathered and dealt with by the application itself, but via a third-party payment clearing system, such as WorldPay or PayPal.
It is unlikely that the next multibillion-dollar company is going to be built off the back of a major new application. The clever developers are following the money – and are creating functional services that can be hosted in the cloud and used by a large number of customers paying small amounts per usage, or a constant monthly subscription. The model is no longer low-volume, high-margin, but high-volume, low-margin.
Even within an organisation, this is still the right approach: create a function that can be called by different surrounding systems as required, that can be plugged in and out as something better comes along; that can be easily optimised, updated and upgraded as required without the need for dependent, hard-coded upstream and downstream systems having to be changed.
It is strange that the main area for such innovation has been through tablet and smartphone devices. The easy access to small functional apps at low cost has whetted users’ appetite for the same approach within the workplace. But most of these small apps are monofunctional: it is still very difficult to pull them together to create a solution to a multi-faceted problem.
Home automation via the internet of things (IoT) is beginning to drive a need here: there is a much greater use of capabilities such as IFTTT (if this, then that) programming and the use of home hubs that enable multiple different devices to work together behind a single front end, such as Amazon Alexa or Google Assistant. There are a number of techniques that developers can use to become cloud-native. We are now in the time of the application programming interface (API) economy. Any service must have an open API, so that others have a common and standardised means of accessing the capabilities of the service being provided.
A prime example of this for web-based services is to adopt a ReSTful approach. ReST is the Representational State Transfer capability – a set of common calls and responses that can operate in a stateless manner. ReST is optimised for performance while providing reliability and future-proofing through being an extendable interface.
Any function or service must also be written to be easily updatable: approaching the writing of functions in a manner of cascade or waterfall projects will not be sufficient to support a business’ needs. Instead, it is far better to take a well-ordered and controlled DevOps approach, using open-source tools such as Jenkins, Puppet and Chef, possibly combined with application release automation systems such as CA Automic.
Aim for the three “CDs” of continuous development, delivery and deployment to be able to get new functionality out in response to requests from the business and users within days or weeks, rather than months or years.
Ensure that the function is abstracted from underpinning resources. It is a waste of time writing a new function that has deep dependencies on, for example, the amount of CPU it requires, or a certain type of storage subsystem. Cloud allows for all of this to be abstracted, and the overall scalability of a function should then no longer be restricted by the code – it should only be constrained by the amount of resources that the administrator wants it to have at any moment within the cloud.
Read more about cloud native application development
Microservices technology can pave the way for companies to decentralise the way they build software to deliver innovation and reduce the cost of failure.
Applications built out of independently deployable modules are the future of flexible solution development.
Ease of provisioning
The use of code being compiled and then directly provisioned to a platform is still strongly with us, but the future is pointing towards some form of containerisation, such as Docker, rkt or LXD. By placing code within a container, it makes it easier for the function to be delivered to a range of different platforms, as there is again less dependency between the software and the underlying physical platform than has previously been the case. Systems such as Kubernetes or JuJu can help in ensuring that containers are suitably managed.
Fully define each service with metadata and context. It is likely that the future will see the payload of such containers reduce to being single-function services (microservices). Ensure that any such microservice has enough metadata provided with it for others to make sense of what it does.
Development portals will need to see the microservice and to be able to offer it for use to any individual developer, so there needs to be enough information for this to happen automatically. However, this must not be the only focus for the provision of metadata – the future of loose-coupled, high-performance, real-time composite applications is predicated on metadata and context that can be used to bring together microservices on the fly in a fully automated and orchestrated manner.
For a cloud-native composite application to be able to be built dynamically in this way, the orchestration systems responsible for pulling everything together will have a need to be able to understand what your function does and how to use it. Advanced systems, such as EnterpriseWeb, can figure this out and create the metadata that enables it to define and create the required integrations and orchestrations for deep and end-to-end automations. Other systems may need a standardised set of data available that provides them with the information they need to be able to apply the integrations.
Don’t reinvent the wheel
There are already lots of publicly available services covering things like calendaring: use these rather than writing one that fails as soon as leap year comes along. Look to both commercially supported services available as public cloud offerings, as well as discrete code chunks from supported sites or community groups. Such sites will generally provide feedback from others saying how good the coding is and whether it does the required job or not. Use of pre-prepared code in this way can drastically cut down on coding time as well as error identification and management down the line.
If you are operating within an existing business with its own datacentre (or using a colocation facility), don’t forget to look at what you already have available to you. Although the creation of cloud-native applications from the ground up requires a different approach in coding and the composition of the resulting overall environment, many services may already be there, hidden with existing enterprise apps.
The secret is to be able to abstract specific functions from within the overall monolith of the main application, making them available as callable functions that can be used by other systems. Here again, companies like EnterpriseWeb and CA Automic can provide the capabilities to identify where islands of data and functionality can be pulled into a far more open and responsive overall cloud-based platform.
Overall, the move to writing cloud-native apps requires a fairly fundamental change in how an organisation’s IT department views its development, test and operations systems. The key is to think small, using containerised microservices as a starting point, mixed with intelligent orchestration and automation systems to provide a portfolio of services and applications that deliver far more dynamic support to the business’ needs.
Clive Longbttom is founder of Quocirca.