Cloud Computing Köln

The path to modernizing mission-critical applications

In a world where business disruption is the rule and not the exception, enterprises need IT environments that are designed to yield real innovation by enabling continuous, iterative development. Flexible, agile platforms allow organizations to develop new business models and deliver product innovation and deployment, as well as enable employee productivity and customer engagement.
Cloud adoption continues to grow, while migration to both public and private cloud infrastructure is already mainstream. Broader IT transformation efforts are picking up steam as well, including modernization with containers and microservices, and adoption of cloud-native tools and DevOps processes. Organizations must simultaneously develop modernization strategies for legacy workloads, adopt cloud-native approaches for application development, and integrate the old and the new within a common management and operations framework.
Overcoming four common application modernization challenges
According to 451 Research’s recent Voice of the Enterprise Digital Pulse: Workloads & Key Projects survey, over the next two years, enterprises are expected to expand their workload deployment on public cloud from 22 percent to 39 percent. However, private cloud is still the primary workload venue now, growing from 27 percent to 34 percent of workloads. Why? Most organizations, particularly large enterprises, don’t have the luxury of starting all over again on public cloud and therefore prefer to modernize mission-critical workloads in place. Drivers of this IT strategy include using existing infrastructure investments, ensuring security and maintaining application and data dependencies.
What does this mean for the path to application modernization? It’s not a question of “if.” It’s all about when and how. There are multiple challenges to overcome, which include the following:

Deconstructing the monolith. Taking stock of the existing estate generally involves deciding which applications to take on first. The assessment should take into account factors such as the business value of the application; technology, data and business process dependencies; and compatibility with the most basic type of modernization, VM containerization.
Access to talent. Cloud platform skills and cloud-native expertise remain key areas in which organizations are facing serious skills gaps. At the same time, however, skills related to heritage application architectures and customized software are also crucial to the success of modernization initiatives.
Culture. Cloud-native involves a new approach to application development and IT operations. A culture clash between agile IT and traditional work processes can create a bumpy road for organizations focused on modernization.
Ongoing management and orchestration. Ongoing application modernization in increasingly hybrid IT environments requires unified management platforms that can intelligently map workloads to and between IT execution venues, as well as orchestrate executions and performance across all venues, and enable automation.

Converting to a cloud operating model
Successful application modernization is crucial to digital transformation. Organizations that focus on cloud-enabling their applications and adopting cloud-native development techniques are empowering business agility and improving customer experiences. As more and more businesses begin to adopt multiple services, conversion to the cloud operating model is key to creating and maintaining a competitive advantage.
Read the results of the 451 Research Voice of the Enterprise Digital Pulse: Workloads & Key Projects survey to learn more and explore the benefits of the IBM Cloud.
The post The path to modernizing mission-critical applications appeared first on Cloud computing news.
Quelle: Thoughts on Cloud

Secure your Microservices

Microservices architectures are becoming the de facto way developers are thinking about how their applications are constructed. But security remains a top concern to most organizations.  Therefore, it is important to understand the intersection of security and microservices. While not guaranteeing your application will be secure, we can look at some of the capabilities that can be leveraged to address security concerns with microservices.  
OpenShift Service Mesh uses Istio’s three main principles to solve this new paradigm of security. The first one is Security by default, meaning that users won’t need to change any single line of code in order to use its security features. Secondly, Defense in depth where users can integrate their own security services with the service mesh existent ones (for instance, combining it with Kubernetes RBAC system). And last but not least, Zero-trust network that states that Service Mesh won’t consider security measures installed in the underneath platform. Strong identities, mTLS and RBAC are the most common features. Let’s explore the mTLS and how Kiali can help with that.
Start with mTLS
The goal of this section is to implement mTLS communications between all the services in the travel-agency namespace (but not to travel-portal). Before getting down to details, let’s understand what is mTLS. 
mTLS is the short name for Mutual TLS. mTLS is a protocol that applies the TLS authentication protocol in both directions: client to server and server to client. It is a popular authentication protocol for Machine-to-Machine communications where it is important not only to secure that the service is legit but also that the client is who says it is.
In order to achieve our goal, it is necessary to manage two different Istio Objects: the Destination Rule and the Policy. Let’s first add the DestinationRule object that will enforce all the workloads of the namespace to start connections with only mTLS.

In the overview page, Kiali shows the first hint of the mTLS status for each project available. As you can see in the ‘travel-agency’ namespace, there is a hollow lock icon next to the name telling that ‘mTLS partially enabled’. This means that either the security in that namespace is not properly enabled (this case) or there are communications without security enabled.
In addition, Kiali shows anomalies in health of both namespaces. This makes us think that there is an error on the last DestinationRule added. Let’s see what Kiali validations say regarding the validity of that Istio Object.

The screen right above shows the DestinationRule definition added just before through the Kiali editor. In this section, besides the fact of browsing, editing and deleting all kinds of Service Mesh objects, Kiali shows the result of the validity analysis of those objects. (All the validations provided by Kiali can be found here.)
In this example you can see that this DestinationRule has an error on the mode field saying “Policy enabling namespace-wide mTLS is missing”. This means that the service mesh needs a Policy enforcing all the services in travel-agency namespace to allow only mTLS connections. As a result of this error, line 19 is highlighted in red.
After adding the Policy, Kiali remove the error validation from the Policy:

At this point, mTLS is enabled for that namespace. But what if we’re a little paranoid and we want to make sure? Kiali has a useful security layer in the graph where it shows which connections are using mTLS, and at a glance, I can confirm that mTLS is enabled.

On one hand, as promised, the requests responded with 5xx errors are gone because the error has been fixed adding the Policy. On the other hand, you can see that each edge of the graph has now a lock icon right next to it. This means that there is some or all of the traffic using mTLS. On the side panel, Kiali shows the percentage of traffic using mTLS, ranging from 0 to 100%. At the beginning of the transition from non-mTLS to mTLS you will see numbers lower than 100%. As the traffic between services starts flowing, this number should be 100%. 
Going back to the overview page, you can see that the lock next to the travel-agency is full. Meaning that all the traffic within is configured to be mTLS.

One step is now complete
For most customers, application security is comprised of a number of steps, and mTLS is only one of those steps.  However, when moving to microservices and using a service mesh, being aware of the secure communication method available can help you plug one potential security hole.  The visualization of the security status provided by Kiali is one way you can quickly identify known holes as you work toward your application security goals.
The post Secure your Microservices appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift