Schlagwort: 8221

Linux and Windows, living together, total chaos! (OK, Kubernetes 1.5)

The post Linux and Windows, living together, total chaos! (OK, Kubernetes 1.5) appeared first on Mirantis | The Pure Play OpenStack Company.
There’s Linux, and there&8217;s Windows. Windows apps don&8217;t run on Linux. Linux apps don&8217;t run on Windows. We&8217;re told that. A lot. In fact, when Docker brought containers into prominence as a way to pack up your application&8217;s dependencies and ship it “anywhere”, the definition of &8220;anywhere&8221; was quick to include &8220;Linux&8221;. Sure, there were Windows containers, but getting everything to work together was not particularly practical.
With today&8217;s release of Kubernetes 1.5, that all changes.
Kubernetes 1.5 includes alpha support for both Windows Server Containers, a shared kernel model similar to Docker, and Hyper-V Containers, a single-kernel model that provides better isolation for multi-tenant environments (at the cost of greater latency). The end result is the ability to create a single Kubernetes cluster that includes not just Linux nodes running Linux containers or Windows nodes running Windows containers, but both side by side, for a truly hybrid experience. For example, a single service can have PODs using Windows Server Containers and other PODs using Linux containers.
Though it appears fully functional, there do appear to be some limitations in this early release, including:

The Kubernetes master must still run on Linux due to dependencies in how it&8217;s written. It&8217;s possible to port to Windows, but for the moment the team feels it&8217;s better to focus their efforts on the client components.
There is no native support for network overlays for containers in windows, so networking is limited to L3. (There are other solutions, but they&8217;re not natively available.) The Kubernetes Windows SIG is working with Microsoft to solve these problems, however, and they hope to have made progress by Kubernetes 1.6&8217;s release early next year.
Networking between Windows containers is more complicated because each container gets its own network namespace, so it&8217;s recommended that you use single-container pods for now.
Applications running in Windows Server Containers can run in any language supported by Windows. You CAN run .NET applications in Linux containers, but only if they&8217;re written in .NET Core. .NET core is also supported by the Nano Server operating system, which can be deployed on Windows Server Containers.  

This release also includes support for IIS (which still runs 11.4% of the internet) and ASP.NET.
The development effort, which was led by Apprenda, was aimed at providing enterprises the means for making use of their existing Windows investments while still getting the advantages of Kubernetes. “Our strategy is to give our customers an enterprise hardened, broad Kubernetes solution. That isn’t possible without Windows support. We promised that we would drive support for Kubernetes on Windows Server 2016 in March and now we have reached the first milestone with the 1.5 release.” said Sinclair Schuller, CEO of Apprenda. “We will deliver full parity to Linux in orchestrating Windows Server Containers and Hyper-v containers so that organizations get a single control plane for their distributed apps.”
You can see a demo of Apprenda&8217;s Senior Director of Products, Michael Michael, explaining the functionality here:  <iframe width=&8221;560&#8243; height=&8221;315&8243; src=&8221;https://www.youtube.com/embed/Tbrckccvxwg&8221; frameborder=&8221;0&8243; allowfullscreen></iframe>
Other features in Kubernetes 1.5
Kubernetes 1.5 also includes beta support for StatefulSets (formerly known as PetSets). Most of the objects that Kubernetes manages, such as ReplicaSets and Pods, are meant to be stateless, and thus &8220;disposable&8221; if they go down or become otherwise unreachable. In some situations, however, such as databases, cluster software (such as RabbitMQ clusters), or other traditionally stateful objects, this might not be feasible. StatefulSets provide a means for more concretely identifying resources so that connections can be maintained.
Kubernetes 1.5 also includes early work on making it possible for Kubernetes to deploy OCI-compliant containers.
The post Linux and Windows, living together, total chaos! (OK, Kubernetes 1.5) appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis

How do I create a new Docker image for my application?

The post How do I create a new Docker image for my application? appeared first on Mirantis | The Pure Play OpenStack Company.
In our previous series, we looked at how to deploy Kubernetes and create a cluster. We also looked at how to deploy an application on the cluster and configure OpenStack instances so you can access it.  Now we&#8217;re going to get deeper into Kubernetes development by looking at creating new Docker images so you can deploy your own applications and make them available to other people.
How Docker images work
The first thing that we need to understand is how Docker images themselves work.
The key to a Docker image is that it&8217;s alayered file system. In other words, if you start out with an image that&8217;s just the operating system (say Ubuntu) and then add an application (say Nginx), you&8217;ll wind up with something like this:

As you can see, the difference between IMAGE1 and IMAGE2 is just the application itself, and then IMAGE4 has the changes made on layers 3 and 4. So in order to create an image, you are basically starting with a base image and defining the changes to it.
Now, I hear you asking, &#8220;But what if I want to start from scratch?&#8221; Well, let&8217;s define &8220;from scratch&8221; for a minute. Chances are you mean you want to start with a clean operating system and go from there. Well, in most cases there&8217;s a base image for that, so you&8217;re still starting with a base image.  (If not, you can check out the instructions for creating a Docker base image.)
In general, there are two ways to create a new Docker image:

Create an image from an existing container: In this case, you start with an existing image, customize it with the changes you want, then build a new image from it.
Use a Dockerfile: In this case, you use a file of instructions &#8212; the Dockerfile &8212; to specify the base image and the changes you want to make to it.

In this article, we&8217;re going to look at both of those methods. Let&8217;s start with creating a new image from an existing container.
Create from an existing container
In this example, we&8217;re going to start with an image that includes the nginx web application server and PHP. To that, we&8217;re going to add support for reading RSS files using an open source package called SimplePie. We&8217;ll then make a new image out of the altered container.
Create the original container
The first thing we need to do is instantiate the original base image.

The very first step is to make sure that your system has Docker installed.  If you followed our earlier series on running Kubernetes on OpenStack, you&8217;ve already got this handled.  If not, you can follow the instructions here to do just deploy Docker.
Next you&8217;ll need to get the base image. In the case of this tutorial, that&8217;s webdevops/php-nginx, which is part of the Docker Hub, so in order to &8220;pull&8221; it you&8217;ll need to have a Docker Hub ID.  If you don&8217;t have one already, go to https://hub.docker.com and create a free account.
Go to the command line where you have Docker installed and log in to the Docker hub:
# docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don’t have a Docker ID, head over to https://hub.docker.com to create one.
Username: nickchase
Password:
Login Succeeded

We&8217;re going to start with the base image.  Instantiate webdevops/php-nginx:
# docker run -dP webdevops/php-nginx
The -dP flag makes sure that the container runs in the background, and that the ports on which it listens are made available.
Make sure the container is running:
# docker ps
CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                                                                    NAMES
1311034ca7dc        webdevops/php-nginx   “/opt/docker/bin/entr”   35 seconds ago      Up 34 seconds       0.0.0.0:32822->80/tcp, 0.0.0.0:32821->443/tcp, 0.0.0.0:32820->9000/tcp   small_bassi

A couple of notes here. First off, because we didn&8217;t specify a particular name for the container, Docker assigned one.  In this example, it&8217;s small_bassi.  Second, notice that there are 3 ports that are open: 80, 443, and 9000, and that they&8217;ve been mapped to other ports (in this case 32822, 32821 and 32820, respectively &8212; on your machine these ports will be different).  This makes it possible for multiple containers to be &8220;listening&8221; on the same port on the same machine.  So if we were to try and access a web page being hosted by this container, we&8217;d do it by accessing:

http://localhost:32822

So far, though, there aren&8217;t any pages to access; let&8217;s fix that.
Create a file on the container
In order for us to test this container, we need to create a sample PHP file.  We&8217;ll do that by logging into the container and creating a file.

Login to the container
# docker exec -it small_bassi /bin/bash
root@1311034ca7dc:/#
Using exec with the -it switch creates an interactive session for you to execute commands directly within the container. In this case, we&8217;re executing /bin/bash, so we can do whatever else we need.
The document root for the nginx server in this container is at /app, so go ahead and create the /app/index.php file:
vi /app/index.php

Add a simple PHP routine to the file and save it:
<?php
for ($i; $i < 10; $i++){
    echo “Item number “.$i.”n”;
}
?>

Now exit the container to go back to the main command line:
root@1311034ca7dc:/# exit

Now let&8217;s test the page.  To do that, execute a simple curl command:
# curl http://localhost:32822/index.php
Item number
Item number 1
Item number 2
Item number 3
Item number 4
Item number 5
Item number 6
Item number 7
Item number 8
Item number 9

Now that we know PHP is working, it&8217;s time to go ahead and add RSS.
Make changes to the container
Now that we know PHP is working we can go ahead and add RSS support using the SimplePie package.  To do that, we&8217;ll simply download it to the container and install it.

The first step is to log back into the container:
# docker exec -it small_bassi /bin/bash
root@1311034ca7dc:/#

Next go ahead and use curl to download the package, saving it as a zip file:
root@1311034ca7dc:/# curl https://codeload.github.com/simplepie/simplepie/zip/1.4.3 > simplepie1.4.3.zip

Now you need to install it.  To do that, unzip the package, create the appropriate directories, and copy the necessary files into them:
root@1311034ca7dc:/# unzip simplepie1.4.3.zip
root@1311034ca7dc:/# mkdir /app/php
root@1311034ca7dc:/# mkdir /app/cache
root@1311034ca7dc:/# mkdir /app/php/library
root@1311034ca7dc:/# cp -r s*/library/* /app/php/library/.
root@1311034ca7dc:/# cp s*/autoloader.php /app/php/.
root@1311034ca7dc:/# chmod 777 /app/cache

Now we just need a test page to make sure that it&8217;s working. Create a new file in the /app directory:
root@1311034ca7dc:/# vi /app/rss.php

Now add the sample file.  (This file is excerpted from the SimplePie website, but I&8217;ve cut it down for brevity&8217;s sake, since it&8217;s not really the focus of what we&8217;re doing. Please see the original version for comments, etc.)
<?php
require_once(‘php/autoloader.php’);
$feed = new SimplePie();
$feed->set_feed_url(“http://rss.cnn.com/rss/edition.rss”);
$feed->init();
$feed->handle_content_type();
?>
<html>
<head><title>Sample SimplePie Page</title></head>
<body>
<div class=”header”>
<h1><a href=”<?php echo $feed->get_permalink(); ?>”><?php echo $feed->get_title(); ?></a></h1>
<p><?php echo $feed->get_description(); ?></p>
</div>
<?php foreach ($feed->get_items() as $item): ?>
<div class=”item”>
<h2><a href=”<?php echo $item->get_permalink(); ?>”><?php echo $item->get_title(); ?></a></h2>
<p><?php echo $item->get_description(); ?></p>
<p><small>Posted on <?php echo $item->get_date(‘j F Y | g:i a’); ?></small></p>
</div>
<?php endforeach; ?>
</body>
</html>

Exit the container:
root@1311034ca7dc:/# exit

Now let&8217;s make sure it&8217;s working. Remember, we need to access the container on the alternate port (check docker ps to see what ports you need to use):
# curl http://localhost:32822/rss.php
<html>
<head><title>Sample SimplePie Page</title></head>
<body>
       <div class=”header”>
               <h1><a href=”http://www.cnn.com/intl_index.html”>CNN.com – RSS Channel – Intl Homepage – News</a></h1>
               <p>CNN.com delivers up-to-the-minute news and information on the latest top stories, weather, entertainment, politics and more.</p>
       </div>
…

Now that we have a working container, we can turn it into a new image.
Create the new image
Now that we have a working container, we want to turn it into an image and push it to the Docker Hub so we can use it.  The name you&8217;ll use for your container typically will have three parts:
[username]/[imagename]:[tags]
For example, my Docker Hub username is nickchase, so I am going to name version 1 of my new RSS-ified container
nickchase/rss-php-nginx:v1

Now, if when we first started talking about differences between layers you started to think about version control systems, you&8217;re right.  The first step in creating a new image is to commit the changes that we&8217;ve already made, adding a message about the changes and specifying the author, as in:
docker commit -m “Message” -a “Author Name” [containername] [imagename]
So in my case, that will be:
# docker commit -m “Added RSS” -a “Nick Chase” small_bassi nickchase/rss-php-nginx:v1
sha256:148f1dbceb292b38b40ae6cb7f12f096acf95d85bb3ead40e07d6b1621ad529e

Next we want to go ahead and push the new image to the Docker Hub so we can use it:
# docker push nickchase/rss-php-nginx:v1
The push refers to a repository [docker.io/nickchase/rss-php-nginx]
69671563c949: Pushed
3e78222b8621: Pushed
5b33e5939134: Pushed
54798bfbf935: Pushed
b8c21f8faea9: Pushed
…
v1: digest: sha256:48da56a77fe4ecff4917121365d8e0ce615ebbdfe31f48a996255f5592894e2b size: 3667

Now if you list the images that are available, you should see it in the list:
# docker images
REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
nickchase/rss-php-nginx   v1                  148f1dbceb29        11 minutes ago      677 MB
nginx                     latest              abf312888d13        3 days ago          181.5 MB
webdevops/php-nginx       latest              93037e4c8998        3 days ago          675.4 MB
ubuntu                    latest              e4415b714b62        2 weeks ago         128.1 MB
hello-world               latest              c54a2cc56cbb        5 months ago        1.848 kB

Now let&8217;s go ahead and test it.  We&8217;ll start by stopping and removing the original container, so we can remove the local copy of the image:
# docker stop small_bassi
# docker rm small_bassi

Now we can remove the image itself:
# docker rmi nickchase/rss-php-nginx:v1
Untagged: nickchase/rss-php-nginx:v1
Untagged: nickchase/rss-php-nginx@sha256:0a33c7a25a6d2db4b82517b039e9e21a77e5e2262206fdcac8b96f5afa64d96c
Deleted: sha256:208c4fc237bb6b2d3ef8fa16a78e105d80d00d75fe0792e1dcc77aa0835455e3
Deleted: sha256:d7de4d9c00136e2852c65e228944a3dea3712a4e7bcb477eb7393cd309be179b

If you run docker images again, you&8217;ll see that it&8217;s gone:
# docker images
REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
nginx                     latest              abf312888d13        3 days ago          181.5 MB
webdevops/php-nginx       latest              93037e4c8998        3 days ago          675.4 MB
ubuntu                    latest              e4415b714b62        2 weeks ago         128.1 MB
hello-world               latest              c54a2cc56cbb        5 months ago        1.848 kB

Now if you create a new container based on this image, you will see it get downloaded from the Docker Hub:
# docker run -dP nickchase/rss-php-nginx:v1

Finally, test the new container by getting the new port&#8230;
# docker ps
CONTAINER ID        IMAGE                        COMMAND                  CREATED             STATUS              PORTS                                                                    NAMES
13a423324d80        nickchase/rss-php-nginx:v1   “/opt/docker/bin/entr”   6 seconds ago       Up 5 seconds        0.0.0.0:32825->80/tcp, 0.0.0.0:32824->443/tcp, 0.0.0.0:32823->9000/tcp   goofy_brahmagupta

&8230; and accessing the rss.php file.
curl http://localhost:32825/rss.php

You should see the same output as before.
Use a Dockerfile
Manually creating a new image from an existing container gives you a lot of control, but it does have one downside. If the base container gets updated, you&8217;re not necessarily going to have the benefits of those changes.
For example, suppose I wanted a container that always takes the latest version of the Ubuntu operating system and builds on that? The previous method doesn&8217;t give us that advantage.
Instead, we can use a method called the Dockerfile, which enables us to specify a particular version of a base image, or specify that we want to always use the latest version.  
For example, let&8217;s say we want to create a version of the rss-php-nginx container that starts with v1 but serves on port 88 (rather than the traditional 80).  To do that, we basically want to perform three steps:

Start with the desired of the base container.
Tell Nginx to listen on port 88 rather than 80.
Let Docker know that the container listens on port 88.

We&8217;ll do that by creating a local context, downloading a local copy of the configuration file, updating it, and creating a Dockerfile that includes instructions for building the new container.
Let&8217;s get that set up.

Create a working directory in which to build your new container.  What you call it is completely up to you. I called mine k8stutorial.
From the command line, In the local context, start by instantiating the image so we have something to work from:
# docker run -dP nickchase/rss-php-nginx:v1

Now get a copy of the existing vhost.conf file. In this particular container, you can find it at /opt/docker/etc/nginx/vhost.conf.  
# docker cp amazing_minksy:/opt/docker/etc/nginx/vhost.conf .
Note that I&8217;ve a new container named amazing_minsky to replace small_bassi. At this point you should have a copy of vhost.conf in your local directory, so in my case, it would be ~/k8stutorial/vhost.conf.
You now have a local copy of the vhost.conf file.  Using a text editor, open the file and specify that nginx should be listening on port 88 rather than port 80:
server {
   listen   88 default_server;
   listen 8000 default_server;
   server_name  _ *.vm docker;
…

Next we want to go ahead and create the Dockerfile.  You can do this in any text editor.  The file, which should be called Dockerfile, should start by specifying the base image:
FROM nickchase/rss-php-nginx:v1

Any container that is instantiated from this image is going to be listening on port 80, so we want to go ahead and overwrite that Nginx config file with the one we&8217;ve edited:
FROM nickchase/rss-php-nginx:v1
COPY vhost.conf /opt/docker/etc/nginx/vhost.conf

Finally, we need to tell Docker that the container listens on port 88:
FROM nickchase/rss-php-nginx:v1
COPY vhost.conf /opt/docker/etc/nginx/vhost.conf
EXPOSE 88

Now we need to build the actual image. To do that, we&8217;ll use the docker build command:
# docker build -t nickchase/rss-php-nginx:v2 .
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM nickchase/rss-php-nginx:v1
—> 208c4fc237bb
Step 2 : EXPOSE 88
—> Running in 23408def6214
—> 93a43c3df834
Removing intermediate container 23408def6214
Successfully built 93a43c3df834
Notice that we&8217;ve specified the image name, along with a new tag (you can also create a completely new image) and the directory in which to find the Dockerfile and any supporting files.
Finally, push the new image to the hub:
# docker push nickchase/rss-php-nginx:v2

Test out your new image by instantiating it and pulling up the test page.
# docker run -dP nickchase/rss-php-nginx:v2
root@kubeclient:/home/ubuntu/tutorial# docker ps
CONTAINER ID        IMAGE                        COMMAND                  CREATED             STATUS              PORTS                                                                                           NAMES
04f4b384e8e2        nickchase/rss-php-nginx:v2   “/opt/docker/bin/entr”   8 seconds ago       Up 7 seconds        0.0.0.0:32829->80/tcp, 0.0.0.0:32828->88/tcp, 0.0.0.0:32827->443/tcp, 0.0.0.0:32826->9000/tcp   goofy_brahmagupta
13a423324d80        nickchase/rss-php-nginx:v1   “/opt/docker/bin/entr”   12 minutes ago      Up 12 minutes       0.0.0.0:32825->80/tcp, 0.0.0.0:32824->443/tcp, 0.0.0.0:32823->9000/tcp                          amazing_minsky

Notice that you now have a mapped port for port 88 you can call:
curl http://localhost:32828/rss.php
Other things you can do with Dockerfile
Docker defines a whole list of things you can do with a Dockerfile, such as:

.dockerignore
FROM
MAINTAINER
RUN
CMD
EXPOSE
ENV
COPY
ENTRYPOINT
VOLUME
USER
WORKDIR
ARG
ONBUILD
STOPSIGNAL
LABEL

As you can see, there&8217;s quite a bit of flexibility here.  You can see the documentation for more information, and wsargent has published a good Dockerfile cheat sheet.
Moving forward
As you can see, creating new Docker images that can be used by you or by other developers is pretty straightforward.  You have the option to manually create and commit changes, or to script them using a Dockerfile.
In our next tutorial, we&8217;ll look at using YAML to manage these containers with Kubernetes.
The post How do I create a new Docker image for my application? appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis

Why can’t all cloud providers deliver adequate security?

IT security is a top priority for most CIOs. After all, gaps in infrastructure could leave their companies and customers vulnerable to attacks.
So when evaluating a cloud managed services provider, asking the right security questions can be critical in determining if the solution is a good fit. Choosing a cloud solution that meets a company’s unique requirements can help reduce operational costs and drive innovation while enhancing security.
With this in mind,  our IBM cloud security experts highlight six question in this short webcast that, when asked, can help you decide whether a cloud service provider can meet your security requirements.
A focus on security
Source: Redefining Connections: Insights from the Global C-Suite Study – The CIO Perspective, IBM Institute of Business Value, 2016
A recent study conducted by IBM found that 76 percent of CIOs consider IT security their biggest risk. It was far and away the top response.
To avoid potential problems, a cloud managed services provider should incorporate built-in security layers at every level from the data center to the operating system, delivering a fully-configured solution with industry-leading physical security and regular vulnerability scans performed by highly-skilled specialists.
Questions to ask
When deciding whether a cloud managed services provider can meet your security requirements, start with these questions:
1. Who is responsible for security?
The answer may not be as obvious as you think.
Some cloud managed services providers might not take the full responsibility of maintaining a security-rich environment for your data. After they provide the hardware, the security and compliance responsibilities could rest with you. Also, some providers may require an agreement stipulating that your company is responsible for anything you do on your system that might affect your “neighbors” on that same cloud infrastructure.
Choose a cloud managed services provider capable of taking full responsibility for the security of the infrastructure rather than placing the onus on  your company or a third party.
Be certain that your data is managed with the same tools, standards and processes that the provider uses for its own systems.  To avoid confusion that can lead to serious issues later on, make sure this division of responsibility is clearly defined in your agreement with the provider.
2. How do I know security is adequate?
Your cloud solution should be able to help you manage regulatory compliance standards. While some providers may use certifications as a way of demonstrating security, it’s important to know what you’re looking at. Some certifications may cover only certain services or locations.
Choose a cloud managed services provider that covers the security of the entire infrastructure as well as policies and procedures. The security section of the IBM Cloud Managed Services Comparison Guide includes a list of certifications you may want to look for when evaluating cloud providers.
3. What if something goes wrong?
Quick recovery after a disaster is crucial to your business operations. Failure to properly handle outages can lead to lost revenue, productivity challenges and a damaged reputation with your customers.
Choose a managed cloud hosting solution that includes offsite disaster recovery options to help you get back online quickly.  Make sure your agreement includes production-level service level agreements (SLAs) and regular testing of emergency backup options.
To learn more about what to ask and listen for when deciding whether a cloud service provider can meet your security requirements, register for the webcast, &#8220;Six questions every CIO should ask about cloud security.&#8221;
The post Why can’t all cloud providers deliver adequate security? appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

Enterprise cloud strategy: Applications and data in a multi-cloud environment

Say you&#8217;ve decided to hedge your IT bets with a multi-cloud environment. That’s excellent, except, what&8217;s your applications and data strategy?
That&8217;s not an idle question. The hard reality is that if you don&8217;t coordinate your cloud environments, innovative applications will struggle to integrate with traditional systems. Cost management, security and compliance — like organizational swords of Damocles — will hover over your entire operation.
In working with clients who effectively manage multiple clouds, I see five key elements of applications and data strategy:
Data residency and locality
Data residency (sometimes called data sovereignty) defines where a company’s data physically resides, with rules for how it&8217;s handled and transferred, including backup and disaster recovery scenarios. It&8217;s often governed by countries or regions such as the European Union.
Data locality, on the other hand, determines how and where data should be stored for processing.
Taken together, data residency and locality affect your applications and your efforts to globally digitize more than anything else. Different cloud providers allow various levels of control over data placement. They also provide the tools to verify and ensure compliance with residency laws. In this regard, it&8217;s crucial to have a common set of tools and processes.
Data backup and restoration across clouds are necessities. Your cloud services provider (CSP) must be able to handle this, telling you exactly where it places the data in its cloud. Likewise, you should know where the CSP stores copies of the data so you can replicate them to another location in case of a disaster or audit.
Security and compliance
You need a common set of security policies and implementations across your multi-cloud environment. This includes rules for identity management, authentication, vulnerability assessment, intrusion detection and other security areas.
In an environment with high compliance requirements, customer-managed encryption keys are also essential. You should pay attention to how and where they&8217;re stored, as well as who has access to decrypted data, particularly CSP personnel.
Additionally, your CSP&8217;s platform capabilities must securely manage infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), software-as-a-service (SaaS), business-process-as-a-service (BPaaS) and database-as-a-service (DBaaS) deployment models.
Also, the CSP&8217;s cloud will invariably house multiple tenants. Data should be segregated from them with top-level access policies, segmentation and isolation.
Integration: APIs and API management
APIs are the connective tissue of your applications. They need effective lifecycle management across traditional, private cloud and public cloud applications.
Your CSP should provide an API lifecycle solution that includes &#8220;create, run, secure, manage&#8221; actions in a single offering. That solution should also have flexible deployment options — multi-cloud and on premises — managed from a single control pane. That gives you the ability to manage APIs, products, policies and users through one view across your cloud environments.
In assessing a CSP, it’s also worth knowing whether it can integrate PaaS services through a common gateway. Its API platform should be a distributed model to implement security and traffic policies, as well as proactively monitor APIs.
Portability and migration
When taking applications to a multi-cloud environment, you must choose among three migration models. You can &8220;lift and shift&8221; with a direct port of the application to the cloud, perform a full refactor that completely customizes the application, or choose a partial refactor in which only parts of the application are customized.
A lot rides on your CSP&8217;s ability to support these models. Since legacy applications depend on infrastructure resiliency to satisfy uptime, you may not be able to fit them to the CSP’s deployment standards. In fact, such modifications may delay cloud benefits. To address this problem, consider containers for new applications deployed across your different clouds.
Some enterprises tackle migration by installing a physical appliance on the CSP’s premises or in co- located facilities, then integrating it with their applications. If you go this route, understand what the options are, particularly the technical limits with respect to data volumes, scale and latency.
New applications and tooling
To ensure efficiency, operations such as building, testing, and deploying applications should be linked together to create a continuous integration/continuous deployment (CI/CD) pipeline. These tool chains often require customizations when part of a multi-cloud environment. One common error: new applications are designed for scalability in public cloud IaaS or PaaS scenarios, but their performance service-level agreements (SLAs) are not addressed early enough in the cycle. Understanding your CSP&8217;s SLAs, along with designing and testing for performance, are crucial for successful global deployment.
For more information, read IBM Optimizes Multicloud Strategies for Enterprise Digital Transformation.
The post Enterprise cloud strategy: Applications and data in a multi-cloud environment appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

American Airlines soars into cloud with IBM

American Airlines, the largest passenger air carrier in North America, announced this week that it has chosen IBM as a cloud provider.
Specifically, the airline intends to move some of its applications to the cloud and make use of IBM infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) tools. The agreement also means American will have access to the 50 IBM data centers around the world, the Bluemix development platform and analytics capabilities.
Patrick Grubbs, vice president of travel and transportation at IBM Cloud, said the work between IBM and American will include &#8220;customer facing systems as well as back office.&#8221;
American has been looking integrate and streamline its systems since merging with US Airways in 2013.
Robert LeBlanc, Senior Vice President of IBM Cloud, said, &8220;This partnership is about delivering the flexibility to American Airlines&#8217; business, allowing them to enhance their customer relationships and further gain a competitive advantage.&8221;
The new IBM agreement with American Airlines extends a longstanding relationship. In the 1950s, the two companies collaborated to create the first-ever electronic reservation and ticketing system in the air travel industry.
For more, check out ZDNet&#8216;s full story.
(Image via Wikimedia Commons)
The post American Airlines soars into cloud with IBM appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud