The Power of Containers in Bringing Reference Architectures to Life

 Introduction:

In this post, I’m going to describe about some of what we’re doing with containers in some of our client engagements and reference architectures, building on Bluemix and IBM Containers. IBM Bluemix is an open-standards, cloud platform for building, running, and managing applications. With Bluemix, developers can focus on building excellent user experiences with flexible compute options, choice of DevOps tooling, and a powerful set of IBM and third-party APIs and services.

Overview

The majority of Cloud applications today aren’t just one “thing”. They are many, or have a roadmap to get to many “things”

ü  Mobile.

ü  Big Data & Analytics.

ü  Internet of Things.

ü  Cognitive.

ü  Hybrid.

ü  Integrated.

ü  Secured.

These are all the capabilities in new and existing applications that our clients are looking for today. These also happen to be all the capabilities that IBM Bluemix brings to market today. I want to cover two of the larger architecture styles in this post, some of which have the most overlap on the Venn Diagram of “Where are we now versus Where do we want to be” for our Enterprise clients — Mobile and Big Data. This overlap is made possible by the hybrid nature of containers and the IBM Container service on Bluemix.

The true power of Bluemix, IBM’s cloud platform, comes in its flexibility and applicability to a broad number of critical use cases for today’s Enterprise, with a similar experience for the user in both new and existing applications, which we’ll cover across the two different architectural styles.

Mobile

Today’s Mobile applications are much, much more than just an entry in the Apple App Store or the Google Play Store. Many estimate that 70-80% of the effort of building a mobile app is not in developing the front end, but in all of the back-end integration, data storage, security, etc. At a minimum, you need a mobile application server or gateway for secure and managed engagement coupled with services for universal push, location, and data capabilities. In addition, API Management enables access to data in a reusable and scalable way. The entire Enterprise-grade Mobile architecture is documented here and can seem quite daunting at first.

IBM recognizes the increasing challenges our clients have to more quickly and easily build, deploy, and manage mobile applications. To help clients address these challenges, IBM intends to offer the MobileFirst Platform Foundation available for deployment on IBM Containers on Bluemix. IBM also plans to offer an evaluation of the MobileFirst Platform Foundation available for deployment on IBM Containers on Bluemix to help developers, IT professionals, and lines of business assess the offering.

IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remain at our sole discretion.

IBM MobileFirst Platform provides many of the core capabilities needed to quickly and efficiently build, manage, and secure your mobile app projects. Many of the functions of MobileFirst Platform are available as discrete services in Bluemix and on-premises software; however, core enterprise functions for enterprise security, integration and management were only available for on-premises or in VMs that could take special expertise to configure properly. The power of containers enables MobileFirst Platform customers to evaluate the MobileFirst Platform capability with the flexibility to move on-premises, if the business situation requires it. At DockerCon, we intend to demo an early preview of our full MobileFirst Platform Foundation running in the IBM Container service. The same exact code that runs in your data center, the same exact Apps & Adapters you’ve built, the same exact APIs you’re calling, all running in Bluemix.

The same exact experience your Enterprise developers have been delivering your market-cornering Mobile applications to in recent years is available on Bluemix. And when your needs expand, Bluemix has you covered as well — integration with Cloudant, IBM’s NoSQL DB service, for offline data sync is as simple as docker run to connect your container instance to Bluemix services, as well as integration with your current Systems of Record… which brings me to Big Data.

Big Data & Analytics

The problem with Big Data it’s big… and the data is everywhere. To solve this problem, you need a truly hybrid application to access your data anywhere, anytime. There are two concepts in Big Data – taking the data to the compute (the most obvious) and taking the compute to the data (the not so obvious). Starting with taking your data to the compute seems pretty logical, since you have a centralized runtime, your killer app on Bluemix naturally, and you just need to collate your data from many different organizations inside your Enterprise.

To solve this problem, Bluemix provides a Secure Gateway capability to securely tunnel from Bluemix and connect to your Systems of Records, that you specify and control. Bluemix spits out a Docker command for you to run locally, which connects your on-premise System of Record to your Bluemix application via a Secure Gateway client running inside a Docker container. This gateway then provides you with a TLS-secured cloud host and port number for you to access your on-premise data from your application running in Bluemix. The power of the Secure Gateway, Docker, and containers makes it so easy to securely connect your hybrid application to your data centers.

 

continue reading

Introduction to RESTful Web Services

Introduction

REST stands for Representational State Transfer. REST is web standards based architecture and uses HTTP Protocol for data communication. It revolves around resource where every component is a resource and a resource is accessed by a common interface using HTTP standard methods. REST was first introduced by Roy Fielding in 2000.

Representational State Transfer (REST) is a software architecture style that centers on the transmission of data over HTTP, using only the four basic HTTP verbs. It also eschews the use of any additional wrappers such as a SOAP envelope and the use of any state data.

Overview

Representational State Transfer (REST) is an architectural style first described in a doctoral dissertation by a researcher named Roy Fielding. In RESTful systems, servers expose resources using a URI, and clients access these resources using the four HTTP verbs. As clients receive representations of a resource they are placed in a state. When they access a new resource, typically by following a link, they change, or transition, their state. In order to work, REST assumes that resources are capable of being represented using a pervasive standard grammar.

The World Wide Web is the most ubiquitous example of a system designed on REST principles. Web browsers act as clients accessing resources hosted on Web servers. The resources are represented using HTML or XML grammars that all Web browsers can consume. The browsers can also easily follow the links to new resources.

The advantages of RESTful systems is that they are highly scalable and highly flexible. Because the resources are accessed and manipulated using the four HTTP verbs, the resources are exposed using a URIs, and the resources are represented using standard grammars, clients are not as affected by changes to the servers. Also, RESTful systems can take full advantage of the scalability features of HTTP such as caching and proxies.

HTTP Methods

Following well known HTTP methods are commonly used in REST based architecture.

·         GET - Provides a read only access to a resource.

·         PUT - Used to create a new resource.

·         DELETE - Used to remove a resource.

·         POST - Used to update an existing resource or create a new resource.

·         OPTIONS - Used to get the supported operations on a resource.

Basic Rest Principles

v  RESTful architectures adhere to the following basic principles:

v  Application state and functionality are divided into resources.

v  Resources are addressable using standard URIs that can be used as hypermedia links.

v  All resources use only the four HTTP verbs.

ü  DELETE

ü  GET

ü  POST

ü  PUT

v  All resources provide information using the MIME types supported by HTTP.

v  The protocol is stateless.

v  Responses are cacheable.

v  The protocol is layered.

Resources

Resources are central to REST. A resource is a source of information that can be addressed using a URI. In the early days of the Web, resources were largely static documents. In the modern Web, a resource can be any source of information. For example a Web service can be a resource if it can be accessed using a URI.

RESTful endpoints exchange representations of the resources they address. A representation is a document containing the data provided by the resource. For example, the method of a Web service that provides access to a customer record would be a resource, the copy of the customer record exchanged between the service and the consumer is a representation of the resource.

Rest Best Practices

When designing RESTful Web services it is helpful to keep in mind the following:

ü  Provide a distinct URI for each resource you wish to expose.

For example, if you are building a system that deals with driving records, each record should have a unique URI. If the system also provides information on parking violations and speeding fines, each type of resource should also have a unique base. For example, speeding fines could be accessed through /speedingfines/driverID and parking violations could be accessed through /parkingfines/driverID.

ü  Use nouns in your URIs.

Using nouns highlights the fact that resources are things and not actions. URIs such as /ordering imply an action, whereas /orders implies a thing.

ü  Methods that map to GET should not change any data.

ü  Use links in your responses.

Putting links to other resources in your responses makes it easier for clients to follow a chain of data. For example, if your service returns a collection of resources, it would be easier for a client to access each of the individual resources using the provided links. If links are not included, a client needs to have additional logic to follow the chain to a specific node.

ü  Make your service stateless.

Requiring the client or the service to maintain state information forces a tight coupling between the two. Tight couplings make upgrading and migrating more difficult. Maintaining state can also make recovery from communication errors more difficult.

Designing a Restful Web Service

Regardless of the framework you use to implement a RESTful Web service, there are a number of steps that should be followed:

v  Define the resources the service will expose.

In general, a service will expose one or more resources that are organized as a tree. For example, a driving record service could be organized into three resources:

      /License/driverID

      /License/driverID/speedingfines

      /License/driverID/parkingfines

v  Define what actions you want to be able to perform on each resource.

For example, you may want to be able to update a diver's address or remove a parking ticket from a driver's record.

v  Map the actions to the appropriate HTTP verbs.

Once you have defined the service, you can implement it using Apache CXF.

Sr. No.	HTTP Method	URI	Operation	Operation Type
1	GET	/License/driverID	Get list of License	Read Only
2	GET	/License/driverID/1	Get License with Id 1	Read Only
3	PUT	/License/driverID/2	Insert License with Id 2	Idempotent
4	POST	/License/driverID/2	Update License with Id 2	N/A
5	DELETE	/License/driverID/1	Delete License with Id 1	Idempotent
6	OPTIONS	/License/driverID	List the supported operations in web service	Read Only

Conclusion

In REST architecture, a REST Server simply provides access to resources and REST client accesses and presents the resources. Here each resource is identified by URIs/ global IDs. REST uses various representations to represent a resource like text, JSON and XML. Now a days JSON is the most popular format being used in web services. 

continue reading

IBM Bluemix Application Architectures

Introduction

IBM® Bluemix delivers quick and easy cloud capabilities to deploy and maintain your web application, with minimal hassle and overhead.

The IBM Bluemix application architectures and accompanying walkthroughs will allow you to confidently apply industry-adopted standard architecture capabilities into your application deployments.

Overview

There are two main application included in IBM Blue Mix architectures.

v  Web App Hosting

v  Hybrid Data Storage

Web App Hosting architecture

This paper describes vendor neutral best practices for hosting web applications using cloud computing. The architectural elements described in the document are needed to instantiate a web application hosting environment using private, public or hybrid cloud deployment models.

At a high level, Web application hosting supports server applications which deliver web pages containing static and dynamic content, over HTTP or HTTPS. The static content is typically represented by "boilerplate text" of a web page and more specialized content held in files such as images, videos, sound clips and PDF documents. Dynamic content is typically built in response to a specific request from the client, based on content in the request and content derived from a database connected to the web application.

The core component for hosting web applications is the Web Application Server, but to produce a secure, reliable, high performance architecture a number of other components are required, such as firewalls, load balancers, databases, file repositories and content delivery networks. In addition, lifecycle management, operations management, and governance need to be considered for these components. How these functions are accomplished will differ depending on where the components are deployed and how integration into management systems is supported.

When the cloud service is an Infrastructure as a Service (IaaS) offering, all the elements of the architecture will need to be individually acquired or instantiated. In some cases, the IaaS cloud service provider is able to offer some of the elements in a ready-to-run form.

For the case where the cloud service is a Platform as a Service (PaaS) offering, it is often the case that many elements of the architecture are available as part of the offering and only configuration and deployment is required.

The cloud deployment model affects the locations of many of the components. For Public cloud deployment, the elements are instantiated in the public cloud. For Private cloud deployment, the components are instantiated within the private cloud, either on-premises or within a privately managed environment made available by a cloud service provider. For Hybrid cloud deployment, there is an element of choice of where to locate each component, either in a public cloud environment or on-premises, with the choice typically governed by security and performance considerations.

Please refer to the CSCC Practical Guide to Cloud Computing and Security for Cloud Computing: 10 Steps to Enure Success for a thorough discussion on deployment and security considerations for cloud computing including recommendations on how best to address specific requirements.

Deploy cloud-native web apps with minimal hassle and overhead using Bluemix. Bluemix provides open runtimes, DevOps tools, and integrated services to simplify the development, testing, and deployment of apps. Also, Bluemix-hosted apps access a cloud infrastructure for the enterprise that is scalable, powerful, available, and secure.

Components

v  DNS Server – Domain Name System (DNS) Server resolves the text URL for a particular web resource to the TCP-IP address of the system or service which can deliver that resource to the client.

v  Firewall – A Firewall is a system designed to control communication access to or from a system - aiming to permit only traffic meeting a set of policies to proceed and blocking any traffic which does not meet the policies. Firewalls can be implemented as separate dedicated hardware, or as a component in other networking hardware such as a load-balancer or router or as integral software to an operating system.

v  Load Balancer – Load Balancers distribute network or application traffic across many resources (such as computers, processors, storage, or network links) to maximize throughput, minimize response time, increase capacity and increase reliability of applications. Load balancers can balance loads locally and globally. Considerations should be made to ensure that this component is highly available and is not a single point of failure.

v  Content Delivery Network (CDN) – Content Delivery Networks are geographically distributed systems of servers deployed to minimize the response time for serving resources to geographically distributed users, ensuring that content is highly available and is provided to users with minimum latency. Which servers are engaged will depend on server proximity to the user, and where the content is stored or cached.

v  Cache – Caches store information temporarily needed to fulfill a request by the Web Application Server, including session data and other content. The purpose of the cache is to reduce the latency in responding to a request from a client.

v  File Repository – File repositories are devices or applications that store information, data, etc. in the form of files. Access to the file repository generally includes the ability to store, retrieve, delete and search the repository for a particular file. File repositories can use network storage to provide access to shared files.

v  Web Application Servers – Web Application Servers offer web server functionality and integrated application server functionality if it is needed. Web servers are systems that return resources (web content and images for example) in response to an HTTP request and may be configured to handle requests for multiple IP addresses and/or domains. An integrated application server hosts the program logic used to generate dynamic web content. This can involve retrieval of data from files, databases, http-services, sensors, and other sources of data as well as programmatic generation of new data or information. Web Application servers may support clustering, pooling and other high availability and scaling configurations including auto scaling – instantiating and removing application server instances as demand requires.

v  Web servers and application servers can also be instantiated in a 3-tiered setup with separated rather than integrated Web servers and application servers. In that case, there would be separate pools of Web servers and application servers connected via load balancers. The application server would be responsible for accessing databases or other systems.

v  User Directory – User Directory contains user IDs and credentials needed to validate that the user is allowed to access the information or applications being requested in the Web servers and application servers. The directory can be accessed by web servers, applications servers, databases or any other elements used in the web application.

v  Database – Databases are structured sets of data. Typically databases are kept on storage devices connected to computers and/or networks. Replicated databases are a strategy for highly available and reliable systems where data is copied frequently between 2 or more databases, eliminating bottlenecks and single points of failure.

Hybrid Data Storage architecture

Bluemix provides data storage and integration services to develop and deploy hybrid IT architectures — with components in both cloud and non-cloud environments. Enabling secure connectivity among apps and data sources on-premises or in the cloud, Bluemix-hosted apps have access to cloud infrastructure that supports enterprise requirements such as scalability, performance, availability, and security.

v  Bluemix services Start developing your web app with compute technologies – Cloud Foundry, IBM Containers, or OpenStack Virtual Machines. Building your app on these provides direct access to the robust library of Bluemix services.

v  Continuous Delivery Pipeline automates the building, testing, and deployment of apps from your source-code repository to Bluemix.

v  Auto-Scaling automatically increases or decreases the available compute capacity of apps based on your custom policies.

v  SQL Database - Bluemix provides a variety of data services, specific to your app needs. The SQL Database provides a provisioned, relational database to handle your demanding transactional workloads.

v  Cloudant NoSQL Database runs as an operational data store, optimized to handle the high number of concurrent activities required by today's cloud-native apps.

v  Single Sign On provides policy-based authentication services to Node.js or Liberty for Java apps, allowing users to sign in through popular social sites or custom user registries.

v  Data Cache offers in-memory storage to increase the performance and scalability of apps, while lowering overall latency.

v  Object Storage, built on OpenStack Swift, provides access to a distributed, highly-available managed object storage that can be integrated directly into apps.

v  Monitoring and Analytics provides instant visibility and transparency into performance and health without the need to learn or deploy other tools.

v  Secure Gateway Service brings Hybrid Integration capability to your Bluemix environment. A remote client is provided to enable secure connectivity.

continue reading