At the present time, there is a remarkable trend for application modularization that splits the large hard-to-change monolith into a focused microservices cloud-native architecture. The monolith keeps much of the state in memory and replicates between the instances, which makes them hard to split and scale. Scaling up can be expensive and scaling out requires replicating the state and the entire application, rather than the parts that need to be replicated.

In comparison to microservices, which provide separation of the logic from the state, the separation enables the application to be broken apart into a number of smaller more manageable units, making them easier to scale. Therefore, a microservices environment consists of multiple services communicating with each other. All the communication between services is initiated and carried out with network calls, and services exposed via application programming interfaces (APIs). Each service comes with its own purpose that serves a unique business value.

Within a microservices deployment, one must assume that the perimeter is breachable.  Traditional security mechanisms only provide a layer of security for a limited number of threats. Such old-fashioned mechanisms are unable to capture the internal bad actors where most compromises occur. Therefore, it is recommended to deploy multiple security layers and employ zero trust as the framework. This way, the new perimeter and decision point will be at the microservice.

In this day and age, we must somehow enforce separation along with consistent policy between the services, while avoiding the perils of traditional tight coupling, and not jeopardize security. We need to find a solution so that the policy is managed centrally. However, at the same time, the policy should be enforced in a distributed fashion to ensure the workloads perform as designed and do not get compromised.

The cost of agility

The two main drivers for change are agility and scale. Within a microservices environment, each unit can scale independently, driving massively scalable application architectures. Yet, this type of scale was impossible when it was necessary to couple heavy data services along with the application.

The ability to scale and react rapidly increases business velocity, which allows organizations to reap the benefit in terms of cost and resilience and also improved ways of managing and building the application. However, the decentralized nature of agile deployments introduces challenges in terms of governance.

We should keep in mind that we now have a distributed organization with sub-teams responsible for individual microservices, In addition, the patching and updates are carried out in real time. Eventually, this creates a gap that needs to be filled. The gap consists of visibility and the ability to scale policy in a distributed fashion.

Complexity is the enemy of security

The cloud-native approach introduces considerable complexity. Besides complexity, the end user is responsible for securing their own environment. With microservices, there are many more moving pieces and paths of communication, introducing complexity that must be managed. We need to manage this complexity while keeping the holistic view of the application and visibility as to how each component is operating.

The attempt to secure a complex deployment using existing tools does not work and leads to a complicated security solution with complex policies. Complexity is the enemy of security. As security solutions become more complex, they become unmanageable and less secure. There is a requirement for a new unified security framework that can adapt to the different microservice environments while still providing full visibility along with simplified policy management.

You really need to know who is talking at any given point, authenticate the source, and authorize the type of transaction the API communication is trying to do. You should be aware of the specific communication, which is going on within these channels and what should be authenticated and authorized to communicate.

This is impossible to do efficiently unless changes are introduced to the microservices architecture. Microservice deployments are susceptible to an array of security threats. API vulnerabilities, logic attacks, lateral movements, and the inadequacy of traditional security tools bring the systems to a halt like a house of cards tumbling down.

Diverse traffic patterns

Today’s traffic patterns are different from those of the past. Nowadays, there are a lot of APIs connecting inbound and outbound along with internal communication. The APIs are all public, open and customer facing. The administrators are permitting this type of communication in and out of the public and private data center.

There is typically considerable asymmetry between the front-end ingress API and the backend APIs. Considering the customer environment, there is an initial consumer API call, but that propagates numerous other backend API calls to carry out, for example, user and route lookups.

As the microservice environment develops more components, it is difficult to monitor and make sure everything is secure. The deployment of web application firewalls (WAFs) to secure the public APIs and the use of next-gen firewalls filtering at strategic network points cover only a part of the attack surface. We must still assume that the perimeter is breachable along with the high potential for internal bad actors.

Traditional security mechanisms fall short

The network perimeter was born in a different time and traditional security mechanisms based on Internet Protocol (IP) and 5-tuple no longer suffice. The traditional perimeter consists of the virtual or physical appliance such as a firewall, IPS/IDS or API gateway located at strategic network points. Actually, the traditional perimeter with its traditional security mechanisms only provides the first layer of security. Even though it is labeled as defense in depth, still it is far from reaching that status in a microservices environment.

For example, API gateways are meant to manage the inbound calls. APIs are registered with the API gateway, which changes the workflow. They don’t scale in a microservices environment where there could be hundreds of services, each one exposing a number of API’s and each service containing multiple instances.

The API gateway needs to scale not just with the external traffic, but also with east to west internal traffic. This is the order of magnitude that holds the significant share of total traffic. Web application firewalls (WAFs) do not change the workflow but they share some of the challenges of API gateways. It is impossible to create and manage security when policies are not distributed to the workloads. There is a lot of work to be done for just a limited number of APIs that exponentially grow with internal communications. This is clearly not practical in case of microservices deployments.

Next-gen firewalls are typically the central security resource. They are more suitable for north to south traffic flows but not for internal east to west. In this world where everything is HTTP, firewalls do not offer the best visibility and access control. A firewall typically forces security on the source and destination IP and protocols, but in a microservices environment, the regular communication port is 80/443. It is very common for all to use the same port and protocol for communication.

For this to work, the firewall would need to follow the identity of the source and destination IP address along with the source and destination port numbers. It should have the ability to deal with an orchestration system, changing the identity all the time.

Enforcement should be done in a distributed fashion, right down at the workload level. If what you are monitoring and protecting is accessible to the application and application behavior, it matters less where the attacks come from. However, security frameworks based on traditional mechanisms can leave many avenues for bad actors to camouflage their attacks.

The larger attack surface requires a new perimeter

If the security cannot follow the microservices, you need to bring the security to the microservice and embed the security with the microservice. An effective perimeter is the decision point at the microservice that is not set at the strategic points located within the network. The new perimeter is at the microservice layer and everywhere that has an API. This is the only way to protect, especially when it comes to logic attacks.

Logic attacks become more prevalent in a microservices environment. This type of threat is carried out by a sophisticated attacker, not a script kiddy using a readily accessible tool. They take their time to penetrate into the perimeter to silently explore the internal environment and to go unnoticed while accessing valuable assets.

Cloud native applications expose their logic in multiple layers, not just one. Each microservice exposes some application logic through an API and these APIs if not efficiently secured, can be manipulated by a bad actor. A practical example would be an API that is meant to give you information about a single entry in a database. If the bad actor is able to modify the query slightly, they can pull multiple entries in the database that they do not have authority to access. Now, this can be exploited in every single API, which presents a much larger attack surface than before. This can bring about the opportunity for advanced persistent threat (APT).

As stated earlier, the distributed architectures give a much larger surface area. Each one of these small components is exposed to threats. The surface area is the sum of all APIs and the interactions both internal and external of the application. If you examine an API that is exposed to the outside, you would see hundreds of API calls. This offers numerous ways to exploit the vulnerabilities of an externally facing API. Within a kill-chain, the API is not just used to gain access but also as a way to perform lateral movements.

We also have challenges with traffic encryption. A large part of security in the new age of east to west traffic is the ability to have everything encrypted. It is the role of the application to perform the encryption.

In a microservices environment, key management is a difficult task. Besides, IPsec has a very coarse granularity. If you are looking for encryption with finer granularity in this environment then you need a new type of solution.

Solution components: identity

Workloads can be encapsulated in a number of ways such as a virtual machine (VM), bare metal or container. As a result, what’s required is a mechanism to provide a provable and secure identity to the application, not just to the server or container but also to the actual workload that is running. Ideally, identity can be a list of attributes. Think of them as the key-value pairs that describe an object to the level of detail that you want. Indeed, the more detail you have, the better.

The process of providing identity to a service is called identity bootstrapping. You have to trust something in order to provide application identity i.e. there needs to be an external source of truth. Companies such as AWS, VMware, and Octarine provide this by integrating with the orchestration system.

The orchestration system could be anything from vCenter to AWS ECS to Kubernetes. The system monitors events of new workloads being spawned. After validating the newly spawned workload, the workload is provided with the credentials it needs to prove its identity. After validating that it is legitimate, the newly spawned workload is provided with the credentials it needs to prove its identity. This way, the secrets are never kept in the code, container image, or in kubernetes.

Solution components: visibility

Once the identity is taken care of, we must create security based on the secured identity. How do you enforce policy and how does it get represented when you communicate it to something else?

Firstly, you need to rely on the application identity and monitoring traffic at layer 7. This is because on every API call the caller identifies oneself. You can add the identity on the client side and server side, validate the identity and log the API call to a central system.

The central system aggregates all API calls in all deployments for the customer’s environment and provides extensive visibility. This visibility extends over time to include the history of any changes. Such visibility is useful in agile environments.

Solution components: anomaly detection

You must try as much as possible to enforce the policy at the endpoint. However, sometimes in order to detect sophisticated attacks, you have to correlate multiple sequences, such as time of the day, payloads, and geographic access patterns.

Anomaly detection is needed that comprises a component responsible for looking at all the signals at a given time. Further, it should recognize small deviations from the baseline that could not be detected if you are looking at a single endpoint.

Solution components: policy

In the past, policy presented two prevailing themes – ACL distributed policy solutions and segmentation based on VLANs. You really need to start to think about policy being centrally administered but highly scalable and distributed by way of enforcement.

The policy should be based on workload identity and not network identity. With cloud-native, there is no alignment between the identity of a workload and its network identity. You cannot enable security enforcement through pre-defined network policies laid on traditional means.

The policy should also be driven by visibility, enabling feedback about policy and information about violations. This would allow the administrators to update the policy as required.

The promise of cloud-native applications and agile environments has many benefits for business. Cloud-native deployments left to the default lacks proper security tools and methodologies. However, with a guarded approach, you can reach a secure cloud-native agile environment.

The post Securing microservice environments in a hostile world appeared first on Artificial Intelligence.

OverOps has launched a namesake platform employing machine learning algorithms to capture data from an IT environment that identify potential issues before a DevOps team decides to promote an application into production.

Company CTO Tal Weiss said the OverOps Platform is unique in that, rather than relying on log data, it combines static and dynamic analysis of code as it executes to detect issue. That data then can be accessed either via dashboards or shared with other tools via an open application programming interface (API). The dashboards included with the OverOps Platform are based on open source project Grafana software.

That approach makes it possible to advance usage of artificial intelligence (AI) within IT operations without necessarily requiring that every tool in a DevOps pipeline be upgraded to include support for machine learning algorithms, Weiss said.

OverOps also includes in the platform access to an AWS Lambda-based framework or separate on-premises serverless computing framework to enable DevOps teams to also create their own custom functions and workflows.

Weiss said OverOps is designed to capture machine data about every error and exception at the moment they occur, including details such as the value of all variables across the execution stack, the frequency and failure rate of each error, the classification of new and reintroduced errors and the associated release numbers for each event. Log data is, by comparison, relatively shallow in that it is challenging to determine precise root cause analysis when trying to troubleshoot an issue, he said, noting the OverOps Platform offers visibility into the uncaught and swallowed exceptions that would otherwise be unavailable in log files.

DevOps teams spend an inordinate amount of time analyzing log files in the hopes of discovering an anomaly. But as IT environments continue to scale out, the practicality of analyzing millions, possibly even billions, of log files becomes impractical. OverOps is making the case for employing machine learning algorithms to analyze events before the log file is even created, which eliminates the need to find some way to store log files before they can be analyzed.

There’s naturally a lot of trepidation when it comes to anything to do with machine learning algorithms and other form of AI to manage IT. But as the complexity of IT environments continues to increase, it’s clear DevOps teams will need to rely more on AI to mange IT at levels of scale that were once considered unimaginable. For example, while microservices based on containers may accelerate the rate at which applications can be developed and updated, they also can introduce a phenomenal amount of operational complexity. Most DevOps professionals would rather automate as much as possible the manual labor associated with operations, especially if that leads to more certainty about the quality of the software being promoted into a production environment.

Of course, while making use of machine learning algorithms to analyze code represents a step forward in terms of automation, it’s still a very long way from eliminating the need for DevOps teams altogether.

The post OverOps Brings Machine Learning to DevOps appeared first on Artificial Intelligence.

Enterprises are adopting data science pipelines for artificial intelligence, machine learning and plain old statistics. A data science pipeline — a sequence of actions for processing data — will help companies be more competitive in a digital, fast-moving economy.

Before CIOs take this approach, however, it’s important to consider some of the key differences between data science development workflows and traditional application developmentworkflows.

Data science development pipelines used for building predictive and data science models are inherently experimental and don’t always pan out in the same way as other software development processes, such as Agile and DevOps. Because data science models break and lose accuracy in different ways than traditional IT apps do, a data science pipeline needs to be scrutinized to assure the model reflects what the business is hoping to achieve.

At the recent Rev Data Science Leaders Summit in San Francisco, leading experts explored some of these important distinctions, and elaborated on ways that IT leaders can responsibly implement a data science pipeline. Most significantly, data science development pipelines need accountability, transparency and auditability. In addition, CIOs need to implement mechanisms for addressing the degradation of a model over time, or “model drift.” Having the right teams in place in the data science pipeline is also critical: Data science generalists work best in the early stages, while specialists add value to more mature data science processes.

The post Building a data science pipeline: Benefits, cautions appeared first on Artificial Intelligence.

Microservices is an architectural style that builds applications from a collection of loosely coupled services. The protocols used are lightweight and the services are very fine grained.  Each service stands on its own, and as such, makes development, testing, and refactoring of applications easier.  Because each service is independent, microservices enable application development to be more easily split up among developers and teams to allow parallel work.

A recent report on microservices from the results of a RedHat survey taken at the end of 2017 had the following results:

• Developers are using microservices for both new application design and when interact with legacy systems
• Microservice benefits include: Continuous Integration (CI), Continuous Deployment (CD), agility, scalability, higher developer productivity, and easier debugging and maintenance
• Microservice challenges include: management, and diagnostics and monitoring
• Current microservice developers said that they prefer a best of breed approach that is multi-runtime, multi-technology, and multi-framework.

Matt Miller, partner at Sequoia, told Forbes that “if you think about it from a technology point of view, as we have gone from things like the mainframe to client-server to cloud infrastructure to virtualization, each time we have successfully inserted a new layer of abstraction, our quality has gone up meaningfully, the time it takes to develop applications has come down, and so have our costs… That is why we are excited about microservices and think it is so disruptive. For companies looking to adopt it, it is disruptive because it is a huge paradigm step forward in the efficiency that can be gained in building your applications. You can operate the technology aspects of your business, which is more of your business, at a much faster rate than you could before.”

The post Microservices: Streamlining Development by Breaking up Monolithic Applications appeared first on Artificial Intelligence.

We’ve had a very good run for the last 20 years or so with distributed systems development in the enterprise, but time has started to show some of the downsides of traditional development styles. First of all, distributed systems have grown enormous – it’s very common to see corporate websites for retailing or customer service with hundreds or thousands of discrete functions. Likewise I’ve seen many Java EAR files at those customers whose size are measured in gigabytes. So when you have a site that large, and one that may have been originally built 15 or more years ago, there are going to be parts of it that need to be updated to today’s business realities. 

The second business challenge is that the pace of business change is much more rapid now than it was in the 90s and 2000s. Now that the cellphone replacement cycle is down to a year or less, and customers are constantly updating their apps on those phones—the idea that a corporate website can remain static for months at a time is simply not in touch with the times.

These two trends combined together create a challenge for traditional top-down enterprise development styles. It requires an approach that is both more customer-centric and able to react more quickly, and it also requires an architecture that is able to adapt to and facilitate these rapid changes.

Also, in the past, when development cycles were longer, waterfall-based methods were appropriate, or at least not as much of a hindrance as they are now. If you have the luxury of time, then the downsides of top-down approaches are less apparent. As a side effect, that led to the predominance of outsourcing since if you were going to define everything up front anyway, then you might as well perform the programming work where the labor was cheapest. All of those trends are now being called into question.

What do you see that suggests that of microservices and cloud-native development can change this situation or help address these barriers?

Let’s start with a definition of what microservices are. The microservices approach is a way of decomposing an application into modules with well-defined interfaces that each performs one and only one business function. These modules (or microservices) are independently deployed and operated by a small team who owns the entire lifecycle of the service. 

The reason this is important is that this goes back to a very old principle in computer science that was discovered by Fred Brooks – that adding people to a late project only makes it later by increasing the number of communication paths within the team.

Instead, microservices accelerate delivery by minimizing communication and coordination between people while reducing the scope and risk of change.

 Why is this important? Because in order to meet the rapidly changing pace of development we have to be able to limit both the scope of what we are doing and increase the speed at which applications can be developed. Microservices help with that. 

Another critically important factor that you can’t ignore is the importance of the cloud for deployment. The cloud is rapidly becoming the de-facto standard for deployment of new and modified applications. That has led to the rise of “cloud-native” application development approaches that take advantage of all of the facilities provided by the cloud like elastic scaling, immutable deployments and disposable instances. When you write an application following the microservices architecture, it is automatically cloud-native. That is another factor that is accelerating the adoption of the architectural approach.

Now, as great as microservices are, there are some downsides, or at least some place where they’re not always appropriate. We’ve found that while the microservice approach is perfect for what we at IBM call Systems of Interaction, that it may not be the best approach for Systems of Record, especially those that already exist and change slowly and where there may be no maintenance gains from refactoring or rewriting those systems into microservices.

What does IBM’s provide to help enterprises transform their systems to a micro service and cloud-native approach?



We bring several things to the table that help our customers to adopt the cloud-native and the microservices approach. First and foremost is our open-standards based cloud platform, IBM Cloud. You can’t underestimate the important of open standards when choosing a cloud platform, and IBM’s embrace of standards such as Cloud Foundry, Docker and Kubernetes makes it possible for you to develop not only our cloud, but for on-premise private clouds and other vendor’s clouds as well, giving you unprecedented portability.

Second, we have the comprehensive IBM Cloud Garage Method. You can only be successful with cloud-native and microservices architectures if you build them within a methodological framework that includes the kind of practices such as small, autonomous, co-located teams, test driven development and continuous integration and continuous delivery that make the approach viable. Finally, we have our people, particularly in the IBM Cloud Garage. The Garage is our secret weapon in helping customers rapidly move to the cloud and microservices by showing them how to apply the method to build systems on Bluemix using all of the latest technologies, practices and approaches. You gain experience with those approaches and technologies at the very same time that you’re building a minimum viable product – the first step toward adopting the approach on all of your systems.

There are still many enterprises that have concerns about cloud migration from either a security or performance point of view. How do you address these concerns?

I’ve heard these concerns many times and it comes down to the fact that neither security nor performance should be a driving factor. It’s possible to build systems on the cloud that are more secure and more performant than current on-premise systems! The key is that you don’t build them in the same way as you do on-premise systems, and it’s that change that is actually what is difficult for teams to understand. For instance, with security, you have to implement security at every layer; you can’t be satisfied with only securing the front-end of your applications thinking that anything behind your firewall is safe by default. The extra attention makes the overall system much more secure. Likewise with performance, in the cloud you have to build systems that are horizontally scalable – that means you have to develop algorithms that work with horizontally scalable systems – which end up not only being better able to scale and thus perform, but makes them more resilient as well.

What advice can you give to enterprises who are outsourcing and waterfall-oriented and want to adopt agile processes and cloud-native development?

The important thing is that you have to begin by changing your mindset. In many countries we’re starting to see a backlash against outsourcing as firms realize that software assets are an important category of intellectual property— a firm should be responsible for maintaining and creating on their own just as they create intellectual capital of other types as part of their core competency.

Software is everywhere now – the IoT and the Cloud now pervade every part of our lives, and any firm that thinks that writing software is outside of what they should be doing will find themselves quickly replaced in the market by more innovative firms that realize that the software is the critical factor – witness the demise of traditional taxicabs in the face of Uber and Lyft.

Once that first shift is made, then the second shift comes more easily. If you realize that building software is critical to your productivity and growth, then you want to build it as quickly as possible and to be able to try new things without having to wait months for a result. That leads directly to the Agile approach and away from a waterfall-based mindset that views software projects as large, multi-year capital expenditures. If you want to fully embrace Agile methods, then you need a technology base that facilitates that, and cloud-native approaches and microservices architectures give you that platform.

The post Microservices and cloud-native development versus traditional development appeared first on Artificial Intelligence.

he emergence of microservices boosts business agility, enabling rapid application development, deployment and modification. The challenge is baking in microservices security processes. Traditional security processes can’t secure microservices, because the latter work in and communicate between both internal and external environments, according to Amir Jerbi, CTO of Aqua Security, a container security platform provider.

Using microservices makes security easier for developers or architects in some ways and harder in others. In this Q&A, Aqua Security Co-founder Jerbi offers advice on avoiding mistakes in setting up microservices security and balancing the often-conflicting needs for steel-trap security and rapid deployment of and communication between microservices.

What are the security pros and cons of microservices?

Amir Jerbi: Before cloud, you deployed your software on premises. You had to use the on-prem mechanism in order to secure your application. You had to use a firewall, host-based intrusion protection and maybe a code analysis tool and/or a tool to test for insecure coding. However, when deploying that app in the cloud, you had to use different tool sets and methodologies and build and deploy on one or separate cloud bases. With the shift to using microservices and containers, you can actually use the same tool set and methodologies to deploy on prem or in the cloud and even on every kind of cloud platform.

Microservices make it easier to develop an app that can run on multiple cloud platforms, because you’re using the same packaging and the same artifacts, and you can actually secure them exactly the same way. So, microservices can enable greater consistency in the way that you build, deploy and secure software.

What are some mistakes that could be made in developing and deploying microservices and building a microservices architecture that could lead to security issues?

Jerbi: With the monolithic architecture and application, all of the communications between different parts of apps would be internal. Now, to secure microservices, it’s more complex than that. You have multiple microservices running either on the same machine or distributed host, and there is a lot of communication between those microservices. Some of the communication can be on the same machine, some between different machines and some between different data centers.

When there are so many communications done between those microservices, it means that the perimeter is not something that is well-defined. You can’t put everything inside of a box and just protect that box. It’s not enough just to put a firewall in place, because all those communications must be governed and authenticated.

Easier app updating is a benefit of microservices. A developer can just redeploy a single microservice while letting the application run consistently. Doesn’t that require change management to be done differently than before in order to secure microservices and apps?

Jerbi: Yes. You need to make sure that the change that you’re adding to your system is controlled, and the software that is added doesn’t impact overall security of your application. Now, you need to manage so many small pieces, and that will require different mechanisms for authentication.

Microservice systems, many times, are open, allowing communication between the different services without any security control. So, it’s important to find ways to do strong authentication between microservices.

One way to do microservices authentication well is adopting a well-established authentication framework, like TLS [Transport Layer Security], and implementing two-factor authentication between all of the microservices. But to do that, you need to maintain new methods in order to publish security certificates and maintain those certificates. This is very different from traditional authentication, where they only needed to maintain TLS for the web server, which is much easier.

Are there other security perils that come with microservices?

Jerbi: There is a friction between the need for diligence in security and the need to make and deploy changes very, very fast because, well, you can and your competitors can, too.

Cloud deployment runs so fast today that Netflix and Google can roll out updates many times a day. Others want to do the same but often proceed without thinking through the security piece. The result can be pushing new changes into production apps without understanding the security impact of the change.

Traditionally, a security process ran slow. It required multiple intervals. It was a process that touched all along the pipeline. Now, people traditionally in charge of testing software and pushing it very fast to production are now also tasked with security — largely, securing the code. Wisely, many are taking the DevSecOps approach, wherein a group takes charge of security with a standard set of processes, such as two-factor authentication, RASP[runtime application self-protection], threat [modeling, etc.].

Which other approaches for securing microservices do you find useful?

Jerbi: Shift left testing is more focused on developers, and it allows you to do security analysis of your code or your microservices or your packages. Shift left allows you to fail fast and to fail the build, often to fail due to security issues. It might slow down development processes a bit, but it helps developers understand what’s needed from them in order to build applications with better security. Over time, the knowledge that comes from doing shift left will increase the level of overall security in the organization and allow faster deployment times. That’s because the code will be secure before deployment, and there won’t be after-deployment bottlenecks.

The post Aqua Security CTO reveals how to secure microservices appeared first on Artificial Intelligence.

There’s no doubt that digital transformation (DX) is revolutionizing the way we do business, and cloud computing serves as a key cog in the DX machine. Cloud’s elasticity can indeed help digital businesses communicate more rapidly and increase innovation. But to extract full value from the cloud, companies must make sure that they aren’t bringing the equivalent of a cutlass to a gun fight when it comes to migrating existing applications and accelerating software development.

Here is what I mean: many businesses start their migration journeys by lifting and shifting existing on-premises applications into the cloud, making few to no changes to the application itself.  But running such the same old monolithic application architectures in the cloud means that your applications aren’t built to maximize cloud benefits. Just the opposite: They often present scalability issues, increase cost and require time-consuming application support. Ultimately, this will erode DX strategies, which depend on modernizing, rapidly iterating, and scaling applications.

To fully maximize the cloud, companies need to change application models to suit this new environment. At the same time, this model must also work with existing virtualized infrastructures, as cloud and on-premises IT infrastructure must co-exist for some years.

Apps built for DX

So, what to do? Lift and shift can work as a viable first step, if you know that the application already performs well on premises. From there, companies can lift and extend by then refactoring the application, making significant adjustments to it to make its architecture compatible with a cloud environment. They can also opt for a full redesign, and re-write it as a cloud-native application, a much more work-intensive option reserved for high-value apps that require optimal performance and agility. This is a space where the enterprise takes a much bigger leap ahead than their service operator compatriots, streamlining their own networks of their own accord and liberating themselves from vendor lock in.

How can the enterprise go about this? The answer lies in microservices and containers, two high-growth technologies that are powering DX strategies at companies such as Saks Fifth Avenue and BNY Mellon, according to the Forrester Research report, “Why The CIO Must Care About Containers.”

With a microservice approach to application development, large applications are broken down into small, independently deployable, modular services that each represent a specific business process and communicate with lightweight interfaces such as application programming interfaces (API.)

This approach supports DX activities in several ways. Microservices are easily deployed, scale well, and require less production time, while individual services can be re-used in different projects. Thus, developers can work more quickly and update applications more rapidly. There are a couple drawbacks, however.  Frequently accessed microservices require increased number of API calls which can lead to increased latency and degrade the application response time. Moreover, the need to have multiple microservices operate in concert at any given moment creates a multitude of interdependencies within the application. It is therefore becoming more challenging to monitor the performance of these applications and quickly identify the root-cause of performance degradations.

Containerization is a virtualization method that helps solve some of the latency and efficiency problems of microservices. A container bundles applications together with the pieces they depend on, like files, environment variables, and libraries. Unlike traditional virtual machines, however, containers share the same kernel operating system and without the overhead of the hypervisor processing they allow many more microservices to run on each server, thus significantly boosting application performance.

Code-independent service assurance helps address the second requirement for microservices of monitoring the multitude of interdependencies. It allows visibility into the communication and transactions across microservices without the need to instrument the bytecode. This methodology is the equivalent of monitoring wire-data across traditional networks, customized to virtualized and containerized environments. I it is not only application agnostic, but also capable of providing insights at every layer of the service and application stack.

Empowered with this visibility the enterprise will gain greater clarity on their applications and services what is going on across the physical and virtual wires of their infrastructure. In a world where data is currency and application and service assurance are the basis for investment, this method of ensuring visibility and performance is crucial. Add to this ability to detect anomalies that may indicate security breaches, and the resulting solution becomes an integral part of a successful DX and business assurance strategy.

Agility and other benefits

While monitoring and assuring microservices performance may be challenging, it is highly advantageous and drives innovation and business agility. Through the creation of microservices and containers, service innovation and alteration can be conducted with ease and with speed. Adopting microservices would allow enterprises to refactor their applications effectively either before migration or after they lift and shift them to the cloud, as well as to develop from scratch applications that are optimized to operate in private and public cloud environments.

Of course, a cultural change that promotes experimenting, adapting and implementing at a quicker rate will need to be implemented. Moving from a fail-safe to a safe-to-fail environment with microservices and containers provide the perfect opportunity for this if robust service assurance is in place. Along with encouraging a culture of innovation, it will allow the enterprise to be far more rapid when it comes to implementing new services and fixing problems.

This microservices-led architecture combined with robust service assurance will be crucial for bringing the full benefits of agile service delivery and cloud elasticity at reduced cost into play and help the enterprise dominate the game.

The post Why microservices are the foundation to a digital future appeared first on Artificial Intelligence.