Build Highly Resilient Web Services

Digitization has led to new business models that rely on web services. Digital banks, payment gateways & other Fintech services are now available only on web. These web services need to be highly resilient with uptime of greater than 99.9999%

Building such high resilient Web services essentially boils down to seven key components:

High Resilient IT Infrastructure: 
All underlying IT infrastructure (Compute, Network & Storage) is running in HA mode. High availability implies node level resilience and site level resilience. This ensures that a node failure or even a site failure does not bring down the web services.

Data Resilience:
All app related data is backed up in timely snapshots and also replicated in real time in multiple sites - so that data is never lost and RPO, RTO is maintained at "Zero"
This ensures that Data Recovery site is always maintained as an active state.

Application Resilience:
Web Applications have to be designed for high resilience. SOA based web apps, container apps are preferred than large monolith applications.

Multiple instances of the application should be run behind a load balancer - so that workload gets evenly distributed. Load balancing can also be done across multiple sites or even multiple cloud deployments to ensure web apps are always up and running.

Application performance monitoring plays an important role to ensure apps are available and performing as per required SLA. Active Application Performance Management is needed to ensure customers have good web experience.

Security Plan: 
Security planning implies building in security features into the underlying infrastructure, applications & data. Security plan is a mandatory and must be detailed enough to pass security audits and all regulatory compliance requirements.
Software-Defined-Security is developed based on this security plan and this helps avoid several security issues found in operations.
Security plan includes security policies like: encryption standards, access control, DMZ etc.

Security operations: 
Once the application is in production, the entire IT infrastructure stack must be monitored for security. There are several security tools for: Autonomous Watchdogs, Web Policing, web intelligence, continuous authentication, traffic monitoring, endpoint security & user training against phishing.
IT security is always an ongoing operation and one must be fully vigilant of any security attacks, threats or weaknesses.

IT Operations Management:
All web services need constant monitoring for Availability & Performance. All IT systems that are used to provide a service must be monitored and corrective actions, proactive actions need to be taken in order to keep the web applications running.

DevOps & Automation:
DevOps & automation is a lifeline of web apps. DevOps is used for all system updates to provide a seamless, non disruptive upgrades to web apps.  DevOps also allows new features of web apps be tested in a controlled ways - like exposing new versions/capabilities to select group of customers and then using that data to harden the apps.

Closing Thoughts

High resilient apps are not created by accident. It takes a whole lot of work and effort to keep the web applications up and running at all times. In this article, I have just mentioned 7 main steps needed to build high resilience web applications - but there are more depending on the nature of the application and business use cases, but these seven are common to all types of applications.

5 Aspects of Cloud Management

If you have to migrate an application to a public cloud, then there are five aspects that you need to consider first before migrating.

1. Cost Management
Cost of public cloud service must be clearly understood and charge back to each application must be accurate. Lookout for hidden costs and demand based costs - as these can burn a serious hole in your budgets.

2. Governance & Compliance
Compliance to regulatory standards is mandatory. In addition you may need additional compliance requirements. Service providers must proactively adhere to these standards.

3. Performance & Availability
Application performance is the key. Availability/Up time of underlying infrastructure and performance of IT infrastructure must be monitored continuously. In addition, application performance monitoring both direct methods and via synthetic transactions is critical to know what customers are experiencing

4. Data & Application Security
Data security is a must. Data must be protected against data theft, Data loss, data unavailability. Applications must also be secured from unauthorized access and DDoS attacks. Having an active security system is a must for apps running on cloud.

5. Automation & Orchestration
Automation for rapid application deployment via DevOps, rapid configuration changes and new application deployment is a must. Offering IT Infrastructure as code enables flexibility for automation and DevOps. Orchestration of various third party cloud services and ability to use multiple cloud services together is mandatory. 

5 Reasons for All Flash vSAN Storage

1. High Performance  
All flash vSAN with a mix of NVMe, SAS SSD allows for superior input/output operations per second (IOPS) performance needed for all enterprise workloads. vSAN 6.7 can give  more than 500K IOPS with sub-millisecond read/write latency.  When compared to   spinning disks storage systems, all-flash vSAN system wins in all performance benchmarks.

2. Enterprise-class capability & Capacity
VSAN now provides all enterprise class storage performance and security such as Encrption, DeDupe, Compliance with all major standards: PCI-DSS, HIPPA, DISA, STIG, FedRAMP etc. Along with vRealize, vSAN can used for all data center automation functions to quickly provision storage, storage insights, storage resource management etc.

3. Guaranteed availability and resiliency
vSAN storage can deliver 99.9999 percent availability. All flash vSAN delivers high availability and high resilience with vSphere HA, Stretched clusters, Smart Rebuild/Rebalancing  to ensure highest data integrity.

4. Run multiple workloads 
High cluster level storage performance allows users to run multiple enterprise apps within the same cluster. Moreover, vSAN is now certified to run SAP HANA, Oracle, MS-SQL etc. This gives IT admins the confidence to run all mission critical IT apps in vSAN.  In addition to standard block storage services, vSAN with NexentaConnect can provide high-performance NFS file services - to provide unified storage solution.

5. DR & Data protection optimizes all-flash storage
Backup and recovery is always one of the highest IT priorities. VMware tools such as vSphere and other 3rd part tools provide enterprises the highest data protection. vSphere Replication, Rapid Array replication across stretched clusters, Storage vMotion etc., leverage all-flash storage best in class data protection. 

Software Defined Security for Secure DevOps

Core idea of DevOps is to build & deploy more applications and do that a whole lot faster. However, there are several security related challenges that needs to be addressed before a new application is deployed.

Software Defined Security addresses this challenge of making applications more secure - while keeping pace with business requirements for a DevOps deployment.

The fundamental concept of software defined security is the codify all security parameters/requirements into modules - which can be snapped on to any application. For example, micro segmentation, data security, encryption policies, activity monitoring, DMZ security posture etc are all coded into distinct modules and offered over a service catalog.

A small team of security experts can develop this code, review & validate it and make these security modules generally available for all application developers.

Application developers can select the required security modules at the time of deployment. This gives tremendous time to deployment advantage as it automates several security checks and audits that are done before deployment.

Security code review & security testing is done once at the security module level and thus individual security code review of each application can then be automated. This saves tremendous amount of time during application testing time - leading to faster deployment.

Software security is ever changing, so when a new standard or a security posture has to be modified, only the security modules are changed and applications can pick up the new security modules - thus automating security updates on a whole lot of individual applications. This leads to tremendous effort saving in operations management of deployed apps.

DevOps - Continuous Delivery Process

The Concept of continuous delivery includes software development activities, such as continuous integration & continuous deployment. When new features & functions are added, it is tested, and customer feedback is solicited on continuous basis - as part of continuous delivery process. 

7 Principles for DevOps Success

Success today in the App based economy, business success depends on DevOps. Business leaders must understand what it dates to build a mature, effective Continuous Development (CD) practice.

Here are 7 key principles business leaders must embrace and practice.

1. Production readiness 
The fundamental principle behind CD is the ability to deliver a production-ready release on demand. The organization must reach a maturity level in which the application code is always in a production ready state. Production readiness does not necessarily mean that the application is deployed to production on a continuous basis, but rather the organization retains the ability to do so at will.

2. Uncompromised quality
Software quality cannot be compromised at any point and the development organization has to prioritize high quality over new features. Ensuring a consistent high quality requires
developer's responsibility and proper tooling. It demands tiers of comprehensive testing: Unit testing and static analysis before build and automated functional testing, load, and endurance  testing with proper runtime diagnostics tools in place. Quality failures abort the build process until resolution.

3. Repeatable delivery
The entire software delivery process from build through staging to production must be reliably repeatable so that each iteration is performed in an identical manner. This is achieved by adopting IT tasks automation. Repeated manual tasks that are prone to errors and inconsistencies are also wasting expensive IT resources and time. Automation of these tasks is a prerequisite to any successful CD process.

4. Frequent build and integration
A CD environment operates with the notion that changes to the application code between build cycles are minimal. Agile, incremental development is practiced alongside CD to ensure that
the development project is broken into short iterations. Builds are triggered on all code checked-in to ensure that problems are isolated and addressed quickly.

5. Application stack consistency
The application stacks should be consistent and automatically provisioned to eliminate environment configuration inconsistencies. Consistency also accelerates the developer's and IT problem resolution capability as it reduces the failures related to application external dependencies.

6. Diagnostics and application management
High code quality requires problem detection and immediate resolution as defects occur. Fast and meaningful diagnostics data becomes critical to a successful CD implementation. Static analysis and dynamic analysis tools are sequentially deployed during the build cycle providing developers with the insight and drill down data. Lack of developer insight and diagnostics information allows defects to slip through and delay the ability to deliver a quality build.

7. Broad test automation coverage
Test automation is a prerequisite to ensure high quality and production readiness. Unit tests and multiple layers of automated functional tests are implemented to identify potential issues and regressions. Developers are required to develop unit tests for each submitted piece of code. Automated code quality and unit testing during the integration phase should cover at minimum 90 percent of the code. 

Ten Things One Should know about DevOps

DevOps has taken the IT world by storm over the last few years and continues to transform the way organizations develop, deploy, monitor, and maintain applications, as well as modifying the underlying infrastructure. DevOps has quickly evolved from a niche concept to a business imperative and companies of all sizes should be striving to incorporate DevOps tools and principles.

The value of successful DevOps is quantifiable. According to the 2015 State of DevOps Report, organizations that effectively adopt DevOps deploy software 30 times more frequently and with 200 times shorter lead times than competing organizations that have yet to embrace DevOps.

They also have 60 times fewer failures, and recover from those failures 168 timesfaster. Those are impressive numbers and define why succeeding at DevOps is so important for organizations to remain competitive today.

As the DevOps revolution continues, though, many enterprises are still watching curiously from the sidelines trying to understand what it's all about. Some have jumped in, yet are struggling to succeed. But one thing's certain — it's a much greater challenge to succeed at DevOps if your CIO doesn't grasp what it is or how to adopt it effectively.

HPE Server Platforms for Big Data Analytics

Why Use Containers for Microservices?

Microservices deliver three benefits: speed to market, scalability, and flexibility.

Speed to Market
Microservices are small, modular pieces of software. They are built independently. As such, development teams can deliver code to market faster. Engineers iterate on features, and incrementally deliver functionality to production via an automated continuous delivery pipeline.

Scalability
At web-scale, it's common to have hundreds or thousands of microservices running in production. Each service can be scaled independently, offering tremendous flexibility. For example, let's say you are running IT for an insurance firm. You may scale enrollment microservices during a month-long open enrollment period. Similarly, you may scale member inquiry microservices at a different time E.g., during the first week of the coverage year, as you anticipate higher call volumes from subscribed members. This type of scalability is very appealing, as it directly helps a business boost revenue and support a growing customer base.

Flexibility
With microservices, developers can make simple changes easily. They no longer have to wrestle with millions of lines of code. Microservices are smaller in scale. And because microservices interact via APIs, developers can choose the right tool (programming language, data store, and so on) for improving a service.

Consider a developer updating a security authorization microservice. The dev can choose to host the authorization data in a document store. This option offers more flexibility in adding and removing authorizations than a relational database. If another developer wants to implement an enrollment service, they can choose a relational database its backing store. New open-source options appear daily. With microservices, developers are free to use new tech as they see fit.
Each service is small, independent, and follows a contract. This means development teams can choose to rewrite any given service, without affecting the other services, or requiring a full-fledged deployment of all services.

This is incredibly valuable in an era of fast-moving business requirements.

Container Ecosystem

Network Architecture for Ceph Storage

 As data continues to grow exponentially storing today’s data volumes in an efficient way is a challenge. Traditional storage solutions neither scale-out nor make it feasible from Capex and Opex perspective, to deploy Peta-Byte or Exa-Byte data stores. OpenStack Ceph Storage is a novel approach to manage present day data volumes and provide users with reasonable access time at a manageable cost.

 

 Ceph is a massively scalable, open source, software-defined storage solution, which uniquely provides object, block and file system services with a single, unified Ceph Storage Cluster.

 Ceph uniquely delivers object, block, and file storage in one unified system. Ceph is highly reliable, easy to manage, and open-source. The power of Ceph can transform your company’s IT infrastructure and your ability to manage vast amounts of data. Ceph delivers extraordinary scalability –thousands of clients accessing petabytes or even Exa-bytes of data. A Ceph Node leverages commodity hardware and intelligent daemons, and a Ceph Storage Cluster accommodates large numbers of nodes, which communicate with each other to replicate and redistribute data dynamically. A Ceph Monitor can also be placed into a cluster of Ceph monitors to oversee the Ceph nodes in the Ceph Storage Cluster, thereby ensuring high availability.

 

 This architecture is a cost effective solution based on HPE Synergy Platform which can scale out to meet multi Peta Byte scale.  

Use Cases of Ceph Block & Ceph Object Storage

OpenStack Ceph was designed to run on general purpose server hardware. Ceph supports elastic provisioning, which makes building and maintaining petabyte-to-exabyte scale data clusters economically feasible.

Many mass storage systems are great at storage, but they run out of throughput or IOPS well before they run out of capacity—making them unsuitable for some cloud computing applications. Ceph scales performance and capacity independently, which enables Ceph to support deployments optimized for a particular use case.

Here, I have listed the most common use cases for Ceph Block & Object Storage.

Use Cases of Serverless Computing

Key Metrics to measure Cloud Services

As a business user, if you are planning to host your IT workloads on a public cloud and you want to know how to measure the performance of the cloud service, here are seven important metrics you should consider.

1. System Availability

A cloud service must be available 24x7x365. However, there could be downtimes due to various reasons. This system availability is defined as the percentage of time that a service or system is available. Often expressed as a percentage. For example, a downtime of 7.5 hours unavailable per year or 99.9% availability! A downtime of few hours can potentially cause millions of dollars in losses.

365 or 3.65 days of downtime per year, which is typical for non redundant hardware if you include the time to reload the operating system and restore backups (if you have them) after a failure. Three nines is about 8 hours of downtime, four nines is about 52 minutes and the holy grail of 5 nines is 7 minutes.

2. Reliability or also known as Mean Time Between Failure (MTBF)  and Mean Time To Repair(MTTR)

Reliability is a function of two components: Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR) - i.e., time taken to fix the problem. In the world of cloud services, it is important to know MTTR is often defined as the average time required to bring back a failed service back into production status.

Hardware failure of IT equipment can lead to a degradation in performance for end users and can result in losses to the business. For example, a failure of a hard drive in a storage system can slow down the read speed - which in turn causes delays in customer response times.

Today, most cloud systems are built with high levels of hardware redundancies - but this increases the cost of cloud service.        

3. Response Time

Response time is defined as the time it takes for any workload to place a request for
work on the cloud system and for the cloud system to complete the request. Response time is heavily dependent on the network latencies.

Today, If the user and the data center are located in the same region, the average overall response time is 50.35 milliseconds. When the user base and data centers are located in different regions, the response time increases significantly, to an average of 401.72 milliseconds.

Response Time gives a clear picture of the overall performance of the cloud. It is therefore very important to know the response times to understand the impact on application performance and availability - which in-turn impacts customer experience.

4. Throughput or Bandwidth

The performance of cloud services are also measured with throughput; i.e., Number of tasks completed by the cloud service over a specific period. For transaction processing systems, it is normally measured as transactions/second. For systems processing bulk data, such as audio or video servers, it is measured as a data rate (e.g., Megabytes per second).

Web server throughput is often expressed as the number of supported users – though clearly this depends on the level of user activity, which is difficult to measure consistently. Alternatively, cloud service providers publish their throughputs in terms of bandwidth - i.e., 300MB/Sec, 1GB/sec etc. This bandwidth numbers most often exceeds the rate of data transfer required by the software application.

In case of mobile apps or IoT, there can be a very large number of apps or devices streaming data to or from the cloud system. Therefore it is important to ensure that there is sufficient bandwidth to support the current user base.

5. Security

For cloud services, security is often defined as the set of control based technologies and policies designed to adhere to regulatory compliance rules and protect information, data applications and infrastructure associated with cloud computing use. The processes will also likely include a business continuity and data backup plan in the case of a cloud security breach.

Often times, cloud security is categorized into multiple areas: Security Standards, Access Control, Data Protection (Data unavailability & Data loss prevention), Network  - Denial of service (DoS or DDoS)

6. Capacity

Capacity is the size of the workload compared to available infrastructure for that workload in the cloud. For example, capacity requirements can be calculated by tracking average utilization over time of workloads with varying demand, and working from the mean to find the capacity to handle 95% of all workloads.  If the workloads increases beyond a point, then one needs to add more capacity - which increases costs.

7. Scalability

Scalability refers to the ability to service a theoretical number of users - degree to which the service or system can support a defined growth scenario.

In cloud systems, scalability is often mentioned as scalable up to tens of thousands, hundreds of thousands, millions, or even more, simultaneous users. That means that at full capacity (usually marked as 80%), the system can handle that many users without failure to any user or without crashing as a whole because of resource exhaustion. The better an application's scalability, the more users the cloud system can handle simultaneously.

Closing Thoughts

Cloud service providers often publish their performance metrics - but one needs to dive in deeper and understand how these metrics can impact the applications being run on that cloud. 

Getting your Big Data Strategy right

An expert advice on what you need from big data analytics, and how to get there.

Business and technology leaders in most organizations understand the power of big data analytics—but few are able to harness that power in the way they want. The challenges are complex, and so are the technologies. Identifying and investing in key principles will help you navigate that complexity to find the right way to tap the growing pools of information available to your organization.

There are six main factors required to get a big data analytics platform right. Lets take a look at each one of them and explain how companies can get their big data right.

1. Blazing speed

Expectations around data are higher than ever. Business users and customers demand results almost instantly, but meeting those expectations can be challenging, especially with legacy systems. Speed is not the only factor in implementing a big data analytics strategy, but it's top of the list. Customers typically need to run queries on data sets that are 10 terabyte or larger and want results in few minutes.

Typical Business warehouse solutions would take 48 hours or more, In today's high speed business world, results after 48 hours is almost useless.

Time to insight is a top priority for any new analytics platform. Companies need to invest in High Performance Computing (HPC) to get the results in few minutes. With newer in-memory analytics systems  - such as SPARK or SAP HANA, the wait times can shrink to less than a second!

New solutions are fully optimized, enabling it to provide insights on time to fuel bottom-line results.

2. Scalable capacity

Today, It's a given that any big data analytics solution must accommodate huge quantities of data, but it also needs to grow organically with data volumes. Analytics solution must be able to grow in scale as the data size increases. Today, customers can't afford a "rip and replace" options when the database sizes grow.

Business needs a system that can handle all the data growth in a  way that is transparent to the data consumer or analyst - with very little downtime, if any at all. Capacity and computer expansion must all happen in the background.

3. Intelligent integration of legacy tools

Big Data Analytics must work with legacy tools so that business management can have seemless continuity. But it is also important to know which tools must be replaced and when.

Businesses have made investments in these older tools - such as Business Warehouse, Databases, ETL tools etc. Top management is comfortable with these legacy tools. But as data size grows newer data analysis tools will be needed and these new tools will have to work along with legacy tools.

4. Must play well with Hadoop

Big data and Hadoop has almost become synonymous with big data analytics. But Hadoop alone is not enough.While Hadoop is well known, it is built on generic low cost servers, it is also slow.

Hadoop, an open source big data framework, is a batch processing system, meaning that when a job is launched to analyze data, it goes into a queue, and it finishes when it finishes - i.e., users have to wait for results.

Today, Big data analysis needs to be fast - we are talking about high-concurrency in-memory analytics. Companies will still use Hadoop - but find newer ways to run Hadoop without incurring the performance penalties. Newer implementations of Hadoop (ver 2.7.x) and Spark will allow both systems to run in parallel.

5. Invest in data scientists

Organizations must build teams of data analytics experts. Not just hire data scientists, but also invest in tools that allow them to conduct more robust analyses on larger sets of data.

The key to move forward with best possible data analysis solution is to enable data scientists work with actual data sets and not a sample subset. The data analytics development environment must have the scale and size needed to work on actual data sizes, else the answers can go wrong and also leads to longer and more iterative development process.

6. Advanced analytics capabilities

Data Analytics tools and capabilities are rapidly evolving. Newer analytical tools use Artificial Intelligence (AI) tools as businesses move toward predictive analytics.

Big data has moved beyond reporting. Big data analytics is being used to answer very complex questions based on the data in your database. Analytics are now being more predictive, geospatial, and sentiment focused.

The shift toward predictive analysis and other advanced analysis has started. Organizations now—with the way data science has become more and more a corporate asset—there's definitely greater interest in becoming more predictive and more data-science savvy in nature.

Closing Thoughts  

Globally, data is growing at a very rapid rate: 40-50 percent per year. In this environment, every business is going to struggle against an overwhelming volume of data. New technologies are there that can help manage data at that speed and scale.

But having a right big data strategy is vital for success. As new tools, technologies emerge, it becomes critical to have the right strategy to incorporate them into the existing eco-system in a seemless non-disruptive way.

In this blog, I have highlighted 6 main aspects of a big data strategy that helps organizations to get its big data strategy right. 

Why Fintech should embrace DevOps

Making your IT operation DevOps friendly can improve Bank's ability to respond to rapid changes in FinTech deployments.

For many years now, the biggest challenges banks face have been "soft" and cultural as much as technical. CIOs and IT directors need to align with business values, nurture security awareness, and cultivate a forward-facing workforce with considerably more urgency than they apply when they look at, say, a migration to IPv6, certifying SOC2 compliance, or calculating the ROI of a shift from spinning disks to flash memory.

The latest wrinkle for IT is how to befriend DevOps talent, or more precisely, how to leverage DevOps capabilities and resources. This introduction describes DevOps, distinguishes DevOps and IT cultures, and concludes with a handful of specific ideas IT should consider in response to DevOps fashions.

What is DevOps?

Make no mistake: A significant fraction of DevOps practice is fashion, in the sense that belief in the benefits of those practices is far more widespread than objective documentation of the same benefits. That doesn't mean that all of DevOps is bunk. It just means that DevOps deserves the same critical scrutiny from IT as functions like data management, legal, or marketing. All of them ultimately have a responsibility to communicate how they promote the organization's mission.

The "DevOps" neologism aspires to capture collaboration between software development (Dev) and IT operations (Ops) skills and experiences. One sign of DevOps' mind-share is that it has inspired even more contrived targets, such as DevSecOps and Lean DevOps.

DevOps is often explained as a contrast to outdated silos of responsibility. In the latter model, programmers code up functionality, then toss their source code "over the wall" to a distinct engineering or operations crew responsible for delivering that functionality at a production level and scale. Ignorance of operations realities often results in developers choosing architectures or coding styles that scale poorly and fail clumsily, and are hard to monitor.

Similarly, operations staff who work without deep programming insight have only blunt tools to attack such real-world requirements as a sudden need to multiply capacity by a factor of 10 or harden an application against hostile actors.

DevOps practitioners should have sufficiently broad and deep perspective to step around such pitfalls. The current hot market for DevOps hires reflects the expectation that DevOps practitioners should be solidly grounded in both development and operations.

Another strong theme in DevOps culture is that practitioners automate and generally treat as software as much of operations as possible. A traditional operations staff might install and test operating system patches during downtime hours, while dedicated DevOps workers are more likely to have hosts under automatic control so they can launch new resources and migrate workloads during business hours. Similarly, a new version of an OS should be just another configuration element to update.

When things work well, DevOps takes credit for reliable, highly scalable results delivered to customers, with rapid turnaround of feature requests.

Hybrid vigor

Those certainly sound like desirable qualities. Can traditional IT hire a few DevOps practitioners and acquire the goodness for itself?

Yes and no, as with any important question. Yes, there's plenty DevOps can bring to traditional IT. There are also numerous hurdles to overcome to avoid wasting IT resources and annoying DevOps adepts.

Part of DevOps reality in 2017 is intimacy with cloud service providers, from Amazon Web Services (AWS), Google's G Suite, and so on. Most DevOps professionals take for granted the rich ecosystems of management and orchestration that have grown around these services. A traditional IT on-premises environment—where a new host or storage unit might take weeks to approve and physically requisition rather than seconds to select and deploy—can upset DevOps hires profoundly.

How can central, traditional IT best welcome DevOps talent? These following four ideas—right target, tech clarity, broad perspective, and API opportunity—will take you a long way toward making the right DevOps impression.

Right target

First, keep the goal clearly in mind: While the title of this piece targets "friendly" relations, that's a metaphor. The real goal is to promote the organization's business mission; "friendliness" or "comfort" are means to that end. A traditional IT department probably should never aspire to the "leading edge" technology turnover that some DevOps relish. At the same time, a traditional IT department can speak frankly about the specific help it needs from DevOps and the opportunities to apply DevOps principles outside the usual DevOps domains. The right candidates prize that sort of honesty and challenge.

Technical clarity

Clarity about the organization's infrastructure plans is also important. Is the department adopting private cloud on-premises? DevOps can help define its configuration. Has the company decided on a hybrid cloud architected to allow loads to migrate from on-site to off-site and back? Hybrid remains a specialized, narrowly understood technology likely to excite many DevOps professionals. Is the company committed to legacy architectures in its own data center?

A smart company can remain with legacy at that level and simultaneously work to virtualize and streamline management of those legacy resources. Good DevOps professionals can recognize that, although on-premises legacy architecture won't help them keep up with the latest AWS releases, integration and modernization projects offer abundant opportunity to apply DevOps principles and tools. Part of recruitment should be to sort out the DevOps candidates you encounter: Does a particular individual hunger to be at the bleeding edge of technology? Is the candidate's reward more in using existing tools to fulfill the organization's needs? While both prospects can equally claim "DevOps" status, the latter is likely to be a better fit for integration in centralized IT.

It's more than just a GitHub account

The DevOps focus is on automation and lifecycle management. While this applies immediately to provisioning, that focus can help traditional IT in other areas, including capacity planning, availability, and business continuity. Certainly the past decade has seen a great improvement in tooling around performance, but much of that tooling is still poorly understood by traditional IT. DevOps will assume Logstash, Kibana, Redis, Elasticsearch, Nagios, Puppet and/or Chef, a messaging bus, and other such tools are available. Even the most traditional IT departments probably need to open up to these basic building blocks. IT probably also needs to support Git or a comparably modern source code management system, along with an integrated issue tracker and source review manager. The department doesn't have to hand everything over to GitHub—but it better offer something almost as good or DevOps careerists will think they're just wasting their time.

Embrace APIs

Join the API gold rush. APIs represent another (at least?) double-edged sword, of course. Plenty of past IT attempts to provide programmability have resulted in ill-conceived uses that made more work for IT, however much the intent was to encourage departments to construct their own robust applications. APIs play a different role in 2017, one DevOps will insist be supported well. Cooperate with DevOps and they will show how APIs can be published and consumed more inexpensively than in the past.

Blended strengths = enormous opportunity

A traditional IT department in a non-technology company does no one any favors by pretending it is DevOps paradise. If it's clear about its goals and plans, though, and ready to move on from break-fix and physical craftwork approaches, it can present its IT plans as great opportunities for the automation and management DevOps does best.

There's no need to view cloud providers and convergence technologies as enemies to traditional IT. Rather, they are simply new challenges that deserve thoughtful response in support of traditional IT's longtime strengths in business continuity management, security routines, identity management, cost accounting, and so on. The opportunity to blend the strengths of DevOps and traditional IT is enormous, at least for those IT decision-makers clear about their plans and resources to support them.

Fintech needs DevOps, Analytics & Robotics

Note: This article was co-authored with Saraswathi Ramachandra

Fintech has taken the financial world by storm over the last few years and continues to transform the way people use financial services.

In recent times there has been a definite emphasis on the demand for digital transformation of banking & financial services. Fintech has evolved to address this demand. The term Fintech often refers software applications & tools that provides banking & financial services to customers over Internet.

Fintech also represents a massive digital transformation of banking & financial services. All CEOs of Banks & financial services firms are now aware that Fintech is critical for success.  This digital transformation is making every bank & financial company into a software company.

One of the foundations of digital transformation is using software applications to constantly create new channels to engage customers and to keep employees productive.

Fintech is all about delivering financial services to customers on 24x7x365 and this implies delivering quality software releases that meet or exceed user expectations. The pressure on delivering quality services with software - implies firms will have to deliver software in a continuous mode - also called as DevOps mode of delivery.

DevOps model was developed for Ecommerce & Cloud services - where organizations deploy new software several times a day with a very short development-to-deployment cycles. DevOps transforms the way organizations develop, deploy, monitor, and maintain applications, as well as modifying the underlying infrastructure.

DevOps has quickly evolved from a niche concept to a business imperative and now Fintech companies are striving to incorporate DevOps tools and principles.

In this article, Here are six key points that ensure success of Fintech.

1. For Fintech to be successful, DevOps must have buy-in from leadership

DevOps is not about changing the way software is deployed. DevOps is a way of transforming the way business delivers financial services profitably.

The value of successful DevOps is already quantified. According to the 2015 State of DevOps Report, organizations that effectively adopt DevOps deploy software 30 times more frequently and with 200 times shorter lead times than competing organizations that have yet to embrace DevOps.

They also have 60 times fewer failures, and recover from those failures 168 times faster. Those are impressive numbers and define why succeeding at DevOps is so important for organizations to remain competitive today.

While it takes a new set of tools to implement DevOps, Successful DevOps adoption is more than just a specific set of rules or tools, and it can mean different things to different organizations. There are many definitions about what DevOps is — maybe it's about continuous delivery, or it's about release speed and quality, etc. The important part is that however you define DevOps for your business, your explanation should be clear and consistent.

DevOps is not about release speed — it's about meeting the increasing expectations of consumers. DevOps  is not about continuous delivery — it's about streamlining development and removing deployment hurdles in order to function more efficiently.

As Fintech solutions evolves, DevOps becomes the key to deliver changes rapidly. If top leadership is not buy into the DevOps model then it's a much greater challenge - to succeed.

To succeed in Fintech, DevOps must reach its full potential. This implies changing the way the organization fundamentally operates and that requires leadership support to approve, support, and in some cases be willing to lead this transformation.

2. Fintech Software quality is measured by customer experience

Fintech success greatly depends on meeting or exceeding customer expectations. Fintech software is not just a bundle of software, it is about how the bundle of software come together as a whole and offer meaningful, timely and valuable services to customers.

In hyper-competitive landscape, software has to be delivered continuously and with quality. DevOps is the process that delivers continuous improvements. DevOps also addresses the need to streamline software development and removing deployment hurdles in order to function more efficiently.

Knowing the quality of customer experience implies collection of metrics. One needs to look holistically about metrics. Collecting & analyzing metrics which tell how effectively customers are using the software and how well the software is working.

This implies measuring standard ITIL metrics such as Mean Time To Resolution (MTTR) or Mean Time Between Failure (MTBF), Mean RFC Turnaround Time (MRTT), Total Release downtime (TRD) etc can give a lot of meaningful data. But it may not be effectively measuring what customers doing and how well the software is working, this requires Application Performance Monitoring tools.

3. Application Performance Monitoring tools are critical for Fintech

How well a software performs has a direct impact on customer experience. For example, if a transactions take additional time to complete, then customers will not be satisfied with the product.

This implies measuring application performance. There are several tools that measure application performance: Tools that measure application response times, Application read/write latency,  Application resource utilization, Simulated synthetic transaction times etc. This will help spot problems in real-time and respond quickly to mitigate problems.

The key with APM is that it can provide rapid situational awareness or instant visibility into emerging problems so that the right actions can be taken immediately to avoid negative user impact. When APM is integrated with DevOps, software development teams can know what is happening at customer site and respond quickly. This can ensure quality customer experience.

4. Fintech needs lots of data collection & analytics

Analytics are essential for all areas of business, especially when it comes to improving your software strategy. In order to make sure your applications always live up to the quality expectations of your users — and to stay ahead of your competition — investing in an effective analytics solution should be your main priority.

Fintech requires collections of vast amount of data - both in terms of machine telemetric data, APM metrics, DevOps Metrics, ITIL metrics, customer usage metrics ( when, where, how, often) etc.

This data must be analyzed. An ideal analytics solution will be capable of easily correlating application performance with user engagement and business data in order to ensure that all software decisions support and drive desired financial outcomes.

Fintech requires agility in all aspects of business. Manual processes and human intervention impede that agility as they are time-consuming and prone to error.  Analytics also enable for rapid automation. Once data is analyzed and results are known, several decisions and executions can be automated. This has led to a whole new field of software robotics in banks that can automate repetitive tasks for a more efficient workflow.

For ICICI Bank, these "software robots" have been deployed across functions in retail banking, agri-business, treasury, trade and forex. Software robots are being used to automate 20% of  banking transactions. The bank is expecting a significant improvement in its cost-to-income ratio once the initiative is rolled out in full.

Analytics is the compass that guides Fintech. The success of Fintech software is not in the software itself - it is how fast one can measure the effiency, effectiveness of the software and how quickly it can be improved.

Fintech is not just about the software itself;  It's about how that software connects with customers and partners to complete financial transactions - which generate greater value to users.  Understanding the value of analytics as a key element of success is crucial for long term success of Fintech products.

5. Fintech is not just about Software — it's also the way business operates

While Fintech delivers financial services to customers in a fast & efficient manner. Behind the software there is a whole big organization that needs to evolve to deliver quality software in fast continuous mode. Fintech requires continuos development, continuos integration and continuos delivery. The key to success is managing  the development and operations.

Fintech has evolved beyond a strictly software concept. Fintech involves software, IT tools,  applications, and the delivery of tech-based financial services, which in today's digital world is the responsibility of everyone in the company.

Effective Fintech operations involves the whole company collaborating more closely. Even a strictly IT based project touches other teams and departments — like HR or accounting. Those interactions can be roadblocks if they're bogged down in corporate bureaucracy.

Traditional banking corporate structures and processes inhibit efficient collaboration and impede productivity. DevOps culture is about breaking down silos, removing barriers, and improving communication between teams so employees are empowered to get things done faster and more effectively at the same time. It's important to make sure that everyone  understands the business importance of Fintech software, applications, and the competitive advantages of being more agile.

6. Successful Fintech solutions requires constant feedback and feed forward cycles

Fintech is based on agility. Agility implies faster collaboration within the banking organization and faster response to customer issues. The software tools and business processes for Fintech has to be built to deliver feedback or feed forward information throughout the organization.

Rapid data collection, data analytics helps in getting customer feedback in real time and this feedback can be passed to different functions of the bank. In order for different functions of the bank to interact smoothly and provide input that has value, one must have tools capable of focusing on different elements of the Fintech process that can present information in a context that's relevant to each group audience.

Contextual relevance is particularly important in feedback systems. Business operations must create dashboards that present information that matters to them. This enables all groups to monitor current operations and respond in ways that helps the whole organization function more efficiently.