Showing posts with label Business Application. Show all posts
Showing posts with label Business Application. Show all posts

Sunday, 24 February 2019

Making Sense of Public Cloud Investments

The public cloud infrastructure services (Iaas) market, according to Gartner's estimation is reaching $60 billion in 2019 and is growing at 27% YoY (fastest growing cloud services segment) from the previous year. Assuming Asia contributes 25% of the global share, turns the region into a critical geo for cloud vendors to battle for market leadership. 

However, cloud practitioners in Asia are still somewhat battling with what is considered as decade old cloud myths evolving around security, compliance, IT control and short term ROIs when conversing with regional customers riding on conventional structures and work cultures. This includes financial institutions, communication service providers, retailers, manufacturers and other asset intensive industries.

While these are all valid concerns, over the years premium cloud vendors have more than proven that their infrastructure and platform services (IaaS, PaaS) are superior to any single institutional  environment in terms of performance, security, reliability and overall economics to sustain just about any type of workloads. The public cloud values are now evolving rapidly with introduction of newer, advanced services in opensource databases, artificial intelligence, low code coding, and running mission critical workloads, enabling businesses to gain better control of operations as they cut waste, optimise performance, develop the much needed new capabilities and differentiators faster than ever. 

Open-source Database Services

Businesses have been dabbling with open-source databases (as well as open-source operating systems, libraries and tools) even before cloud computing services emerged and was aware of the potential to free organisations from growing commercial database licensing burdens. However, managing these open-source databases required additional training, operational and maintenance resources, apart from the unpredictable fixes and releases from the open source community. These issues limited the usage of open-source databases such as PosgreSQL to a small number of non critical, in-house development projects and applications in the past. 

This scenario changed in the recent years as cloud computing companies started to offer fully managed open-source database services such as PostgreSQL, MariaDB, MySQL and many others. Businesses start to increase adoption overnight by consuming cloud based open-source database services for existing and new applications while gaining new efficiencies, never possible before. The polyglot nature of cloud native development, where multiple types of databases and models are deployed in an application composed of micro-services and API calls only drives this trend further. 

Popularity of open-source databases according to DB Engine Ranking site, is about to converge with commercial databases in 2019 or in the early parts 2020. 

Artificial Intelligence, Machine Learning, Deep Learning

Explore pre-trained ML models

If new to artificial intelligence and its sub domains machine learning, deep learning and transfer learning, take advantage of the various pre-trained models offered by public cloud vendors such as Google, AWS and Microsoft to perform prediction, classifications, natural language processing (NLP), speech processing, computer vision (video, image and object recognition), decision support and planning tasks. 

Start by experimenting solutions to business problems while inflating returns on organisational data assets. This provides an opportunity for the business to quickly reap benefits from readily available models where the team need only prepare data, select features and train the model for required tasks (e.g predictions, classifications).  Trained models can then be deployed with other production applications and systems through APIs to apply learnings on new data samples.

Building custom models..

As the internal team gain experience and get familiarise with ML projects, commence a process to create step-by-step AI playbook to define and prioritise business problems that can be addressed with AI, data preparation, algorithms selection, and developing a model to make predictions. This exercise should involve critical members from business, data science and the engineering teams, ideally aligned to addressing growth challenges, resources optimisation, innovation and enhancing customer experience. 

Machine learning and deep learning frameworks such as Tensorflow, Pytorch, MXNET, Keras, Caffe, Scikit, Microsoft Cognitive Toolkit and Theano, that comes readily packaged with interface, libraries, tools, pre-built and optimised components facilitates fast development of AI models without getting into the details of underlying algorithms and complex architectures. 

Pick a cloud vendor for ML-as-a-service that best fit your needs...

Top public cloud vendors such as AWS, Microsoft Azure, Alibaba and Google provide support to most of the frameworks mentioned above for custom building models apart from their pre trained model offers for common business problems. New developers can benefit from starting with frameworks such as Keras and delve deeper into Tensorflow or other suitable frameworks as they get accustomed with the building blocks and programming languages.

Develop cloud native applications faster ...

Today a challenge sparks an idea, an idea turns into a prototype and a prototype transforms into a multi-platform first release in just matter of days and weeks. Aside from core infrastructure services, cloud vendors offer various advanced services ranging from devop, language SDKs, container orchestration, serverless computing, no to low code development platforms (both proprietary and open-source), APIs, code libraries to ready templates to help organisations accelerate application development arising from sudden business needs. 

Most post cloud applications are series of micro-services connected to one another via APIs leveraging languages, databases and code bases most suitable for the required function and the supporting technical environment.

No to Low Code Platforms

In addition, low code platforms such as Mendix, Outsystems, Google App Maker, Appian, and Microsoft Power App empowers traditional developers, IT professionals and to a certain degree the average business users to accelerate software delivery for business use cases made up of common features and components by simply utilising existing templates, forms, objects, drag and drop of prebuilt features.

Ensure performance of mission critical applications....

Learn which of your mission critical applications are suffering from intermittent or persistent performance issues affecting business processes critical to productivity, customer experience and revenue activities. Cloud vendors offer various services and pricing plans to optimise business applications from SAP, Oracle, Microsoft, IBM and others where data grows exponentially with transactions in time.

Exploring public cloud offers for the aforementioned type of applications can reveal credible areas of savings, operational simplification, performance improvement, speedy delivery of new business requirements, higher utilisation, improved security and compliance. Keeping a revisable record of requirements and working with cloud vendors to formulate cloud contracts to efficiently counter all planned and unplanned workloads can free internal resources for myriad of higher impact business activities.

Know values, learn constraints and strategise for long term...

Ultimately cloud values can vary significantly from business to business depending on the nature of operational model and the overall ecosystem. The four areas mentioned here are general enough for most sectors, though some businesses might benefit immensely from other emerging tech such as augmented reality, IOT, 3D or bigdata platform services.

In addition, identifying constraints that prohibit enterprise architectures from extracting full potential of public cloud eliminates aimless unproductive explorations. For instance legacy apps on rigid centralised architectures that may not gain much efficiencies when moved to the cloud.

Finally having a solid long term strategy, helps. For instance all new development and deployment to take the 'Cloud First' approach, or maintaining a hybrid cloud environment with only unpredictable workloads moving to public cloud or 'Cloud Only' approach where the internal teams build in-house brokerage capabilities to fully monitor its environments on multiple public clouds and perform various optimisation as needed.

Wednesday, 19 September 2018

Application Portability when Switching Clouds

Every business develops and runs a fair bit of custom code applications to automate value chain delivery to customers, partners, employees, and even supplier interactions. Highly progressive businesses are driven by data which means these businesses continuously build, integrate, stage and deploy custom code to improve a range of outcomes namely process automation, user experience, operational visibility, compliance, and governance at dizzying speed.

Cloud services both IaaS and PaaS are natural choices today for development teams when it comes to realising business services internal and external. In fact, Rightscale recently cited in their ‘State of the Cloud Report’, that in average 48% of SMB workloads run on public clouds.

While healthy public cloud adoption is projected to continue among SMBs at slightly higher pace than enterprises, there is no denying that decision loops concerning the tools and cloud services selected are primarily dependent on the development models (continuous integration / continuous delivery) in practice and often comes with some degree of compromise made between available budget, source code control, speed of development, application portability and interoperability in the future.

Requirements and priorities change

Business priorities change as product or service adoption increases, market factors open new opportunities, competitive landscape tightens or new innovations enter the playing field, all of which involves scaling at a pace never imagined in the pre-internet era. Public clouds large and small, without a doubt power millions of businesses to build solutions quickly and cost effectively with a lot less overhead to meet growth objectives. However, a judiciously selected cloud partner today may cease to be relevant in a future point.


Over time, businesses may need to reassess relationship with existing cloud providers for various reasons ranging from  cost optimisation, security, governance, vendor lock-in, overall performance, cloud bursting to new technology requirement for AI, IOT, VR/AR/MR, 3D and mobile, making application portability a key concern for businesses wishing to switch cloud providers.

Switching public cloud providers in alignment with business goals

Many ISVs for instance may have chosen to develop and deploy new age applications such as IOT for instance, on a certain PaaS service to reduce cost of building the infrastructure and platform themselves. As business grows, the once economically viable solution begins to blow out of proportion financially as usage base explodes. In this case the business is left with two scenarios; one they could look for another provider with similar or equivalent PaaS services at better price points; the second is to choose a IaaS provider and construct their own PaaS layer for more control over application dependencies (e.g. data services, runtime, OS, networking, encryption, and virtualisation).

Application re-platforming processes and routines differs cloud to cloud

The cloud platform on which an application runs and DevOp environment determine how tools (e.g. Ansible, Chef, Puppet and etc.), automation and standardisations are applied in simplifying deployment when migrating applications from one cloud provider to another.

While a standard process perhaps can be established to automate packaging, conduct optimisation, generate VM or container images and orchestrate deployment artefacts, the knowledge sets or expertise involved varies from one cloud platform to another. Though, there are several steps and best practices that can be adopted by DevOp to ensure portability of applications and data today.

Choose cloud providers that support Open Virtualisation Format

Chose to work with cloud service providers that support widely accepted application packaging formats such as the ‘Open Virtualisation Format (OVF)’, formulated and recommended by the Distributed Management Task Force (DMTF). This method standardises packaging of virtual machine based software regardless of cloud platforms which means migrating to a new environment or multiple clouds is swift and resource efficient.

Containerise applications

Another best practice that is gaining momentum recently, is to re-platform applications running on virtual machine instances to a container based platform such as Docker. Containerisation packs application code and all dependencies in a container image that is a repeatable artefact and multiple containers can be deployed on a single VM sharing the same resources. Aside, from the obvious administrative efficiencies and cost savings, this method is ideal to support microservices development architecture (or polyglot architecture) and distributed applications on serverless cloud instances and virtual machines.

Container orchestration and cluster management solutions such as Kubernetes and Docker Swarm facilitates orchestration, clustering, scheduling and integration of large number of container images and typically is sufficient to scale applications as needed. Consider both tools and a proof of concept with each technology, using real-world workloads.

Open standard interfaces and APIs

Open APIs and vendor specific APIs (extensions of SOA architectures) allow users to move data and expose services between clouds while masking complexities behind any one interface (e.g. functional, admin, business). In a real world situation the use of vendor specific APIs are unavoidable even in a ‘open standards friendly’ DevOp environment, especially when the business footprint in a particular cloud is significant.

API management is mandatory in maintaining balance and isolating refitting work when necessary. Security concerns should be maintained throughout the linkages by deploying third party access rights management and other tools, as data securely travels between clouds.

Adopt multi-cloud management platform

Another method to facilitate cloud migration is to implement a suitable multi-cloud management platform that integrates multiple public cloud environments (e.g. AWS, GCP, Azure, Digital Ocean and etc.) including private clouds. This creates an overlay that masks underlying platform differences that allows for easier movement of applications, workflows, and data.

Build own PaaS

Vendor lock-in and portability issues are higher in PaaS services than in IaaS. One option to reduce such reliance is to build an in-house PaaS with tools such as Dokku and Flynn, an open source platform solution for everything that is needed for running applications in production.

Conclusion

Portability and interoperability between clouds is a journey that begins from the point a business on-boards its first cloud service.

Containerising applications, automating deployment processes across multiple clouds, building tools, creating a controllable PaaS layer or at least selecting one that has an equivalent alternative, leveraging open technologies wherever possible, using standard APIs and abstracting integration layers are some of the best practices that can be adopted throughout a cloud lifecycle to ensure smooth exit when need arises. These same best practices reduces vendor lock-in,  unexpected cost spirals, time and material needed to move workloads across public clouds.

Applications and systems with below average portability scores simply don't make the cut as a good migration target to other clouds. In some cases, it might be even easier to just recreate them on a new platform.

Migration processes too must be planned and executed in systematic manner with necessary tooling and automations in place to create a repetitive migration asset that includes the learnings that can be shared with the entire team.

Last but not the least, when porting over to the new cloud, systems must be fully tested and stabilised prior to terminating the old environment in ensuring business continuity.

Tuesday, 11 September 2018

Application Interoperability in Multi-Cloud

Some business problems, never gets old. Interoperability among systems or application is one such issue that requires varying degree of treatment depending on the type of organisation and business stage. This article penned by Let's Kopi is most suitable for startups and SMBs.

A hybrid technology environment is inevitable for any business

Organisations depend on business applications to empower various capabilities to optimise operations, generate growth, enhance customer experience, and accelerate innovation. A typical enterprise technology architecture today delivers these
capabilities by cleverly balancing in-house solutions with a number of Saas services (e.g. Salesforce, Service Now, Box, etc). Though, most post millennial startups are built on cloud-first strategy, which means an internal datacenter does not emerge until business matures with a satisfactory level of solution adoption and customer base.

Business processes transcend cloud and non-cloud applications 

In either scenario, businesses ends up with an enterprise technology environment that spreads across the in-house datacenter, hosted datacenters and various public clouds. Stringent industry compliance, data security, privacy, and call for other regulatory requirements will continue to push at least some parts of the business systems to on-premise deployment. This means critical business processes will continue to transcend several applications to invoke one another in completing workflows, share data, exchange messages, and push results to performance dashboards across a hybrid and multi-cloud environment.


Building integration between applications is necessary….
Linking and integrating applications residing in cloud and non-cloud environment is a common undertaking for businesses that depends on automated processes, mobility, data, and insightful predictions for superior performance, productivity, and production. For instance, a business may integrate a Saas CRM with on premise sales systems to trigger ‘billing’ and ‘delivery’ request when an order is received. A CSP may connect a cloud based customer loyalty mobile application with on-premise ERP and CRM to make offers and process purchases in realtime.

Plenty of tools and methods to isolate integration between applications

There are literally hundreds of tools and services to link on-premise applications with SaaS services to connect processes, orchestrate end to end workflow, ensure data synchronisation, promote data consistency, standardise business rules, enforce security policies, and achieve a seamless business façade (in terms of UI) for users.


Most SaaS service providers offer a range of APIs and even offer PaaS services to extend their SaaS offerings (e.g. Salesforce, Service Now). Pure play integration vendors focus on solutions such as SOA middleware, ESB, EAI and other GUI based tools which enables developers to create interfaces and APIs to suit respective business need and use case.

For instance elastic.io, WSO2 and Cloud Elements are pretty decent option for SMB and smaller companies (based on product and price) looking to isolate integration layers that connect the various technology environment owned by the organisation. While companies such as Mulesoft, Infomatica and Snaplogic may carry a much mature and extensive range of offerings, suited for larger organisation with much complex IT environment.

What approach and which solution?

Ultimately, developers can choose between performing a point to point integration or establishing a middleware integration layer that promotes fluid linkages between systems without changes or minimal impact to source applications. The later being the best practise of the majority. The selection of methods and tools however depends on three critical factors as stated below:


1. The use case – what the business intend to achieve with the integration? For instance data consistency, data exchange, message exchange, end to end workflow or a common UI to access all business app.

2. Requirements – the relevant systems may run on different operating systems, databases, libraries, and written in different languages. The selected tools must be able to support and mediate these environments.

3. IT realestate – how big is your environment? How many business applications? Where they reside? In a very small setup, point to point integration may prove to be fast and economical solution. A rapidly growing environment on the contrary, can benefit from a middleware integration layer.

Sizing up the above can help determine the level of complexities and resources, when it comes to integrating requirements in hybrid environments, switching Saas providers, and ensuring business compliance.

Recommendations - don't overpower integration requirements

There is no single silver bullet for enterprise application integration challenges especially in our current state where public clouds are gauging more of our datacenter and on-premise systems. Selection of tools rely heavily on the specifics of the use case, requirements, dependencies, existing IT landscape and even business strategies to avoid vendor lock-in.

Nevertheless, good decisions can be made by zooming into the problem in hand with a bit of foresight. For example if connecting two applications, then making use of available APIs will be sufficient without the need of any high end integration middleware. But if the this scenario continues to involve other systems and applications, then an integration middleware or tool becomes mandatory. In intermediate situations, the business can also custom build integration interface on-premise or on a PaaS platform provided by cloud vendors.

A final reminder is that to meet integration requirements sufficiently without the need to overpower the integration layer for tasks that has not emerged in the integration roadmap, just yet. A common mistake many small companies make, is to purchase tools that are sold as future proof and broader in application at higher premium. These tools end up under utilised while businesses continue to pay a premium year after year. Tools change radically as new technologies enter our environment and should only be selected based on known business requirements.