Decision Framework for Building Platform as a Service (PaaS) based Government Services

Size: px
Start display at page:

Download "Decision Framework for Building Platform as a Service (PaaS) based Government Services"

Transcription

1 Decision Framework for Building Platform as a Service (PaaS) based Government Services Ratko Mutavdžić Microsoft Croatia, Zagreb, Croatia ratkom@microsoft.com Abstract - PaaS is the operating environment of the cloud with the tools you need on demand to create and host online services, software, Web sites, and mobile applications. With PaaS, you can concentrate on delivering applications rather than on the underlying infrastructure, which a service provider maintains and updates in its data centers. With PaaS, government can develop new applications or services in the cloud that do not depend on a specific platform to run, and you can make them widely available to users through the Internet. PaaS delivers cloud-based application development tools in addition to services for testing, deploying, collaborating on, hosting, and maintaining applications. The open architecture of PaaS can support integration with legacy applications in the government and interoperability with onsite systems important considerations because government operates in a mixed IT world. Interoperability gives you the flexibility to take advantage of cloud benefits while retaining data and applications on-site as needed. This paper will showcase new decision framework model that will enable governments to decide what type of PaaS implementation Government can drive, and what level of flexibility, given the fact described above, that platform needs to have. I. INTRODUCTION An increasing number of companies and government organizations are turning to cloud services to increase the productivity of their workforce. We are seeing widespread adoption of cloud-based services and productivity tools, which enable always-on access to s and files from virtually anywhere. Businesses are also running different applications in the cloud. Dramatic costs savings are a primary driver and benefit of cloud computing. The reality is that on premise computing can be expensive: you need to buy the hardware and software and pay people to install, configure, test, maintain, upgrade and secure everything. Not to mention real estate, bandwidth and energy costs. With cloud computing, somebody else manages and maintains these systems, and you pay only for what you use. Using computers in the cloud makes a lot of business sense, but in the long term using the cloud to go beyond business as usual. There are thousands of examples of organizations that have harnessed the power of cloud computing to introduce new services even build brand new businesses more quickly and less expensively than ever before. In the public sector, cloud computing has been used to enhance everything from public transportation to healthcare to education and emergency services. The cloud is really about using massive computing power stored in huge data centers. In cloud computing, data and processing (i.e., storage and computing) are moved out of the direct control of individuals and IT departments and centralized in shared data centers managed by the cloud service provider. This is has important policy implications in areas such as data security, privacy and sovereignty. II. MAIN CHARACTERISTICS OF CLOUD COMPUTING Definition by NIST defines Platform as a Service as the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider [1]. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations. Platform as a service (PaaS) is a generally referenced as a middle layer services stack that exists in the cloud environment and that we usually refer as application infrastructure services. Also, that services include technologies of application servers, database management systems, portals, application and data integration, business process management suites, messaging and many other forms of application infrastructure. It is important to note that all those systems must be and they are available in the form of services. [2] Cloud computing can benefit governments in three areas: increasing national competitiveness, enhancing citizen services and driving down costs. Cloud computing has the potential to catalyze job growth and spur sustained economic growth, in part by facilitating a knowledge economy. Governments can use cloud computing to engage and inform citizens and organizations more effectively and to deliver enhanced, more efficient services. For instance, cloud computing can improve healthcare by providing broader, more timely access to electronic health records and other medical information. It can provide teachers with new tools that can turn classrooms into more vibrant MIPRO 2012/GLGPS 2027

2 learning places. And it can dramatically increase the ease and speed with which people access and share information enabling improvements in everything from roadway maintenance and green living to revenue collection and emergency management. III. PLATFORM AS A SERVICE AS INTEGRATION PLATFORM Every modern platform as a service has several main elements that describe the characteristics of the service: compute, storage, application experience, security and identity. A. Compute One of the core services for a PaaS environment is compute. In this definition, compute refers to the ability for a developer to deploy and run an application on a platform provided by a vendor. The platform is responsible for ensuring that incoming requests are served correctly to users accessing the application, and adhering to any service level agreements, especially around infrastructure availability. The platform offered to the application provider will normally support one or more programming languages together with a set of core services for invoking the programming code (e.g. pages, background tasks, queues, etc.). The application provider is responsible for creating a package for deployment which will include the developer s code, any required libraries for the platform, and configuration for that deployment. The PaaS vendor will typically offer a custom set of configuration options which allow the application provider to specify how the application will be deployed (e.g. what locations, how many machines, entry points to the application, etc.). B. Storage All applications typically require some kind of storage, and this is also true of applications that run in a PaaS environment. Unlike applications that run on-premise however, storage in in the cloud can take many forms, often optimized for different types of data. These can include one of the following four storage mechanisms: Relational Storage. A familiar and well used storage option for many developers is a relational database. Many PaaS vendors offer, or are starting to offer, a relational storage option for developers. Non-Relational Storage. One of the drawbacks of many relational storage engines is that they don t scale well across multiple instances. They tend to work well for databases up to a certain size, but for more distributed queries (e.g. querying user profiles on Facebook), an alternative is often required. This alternative tends to be a schemaless, structured store. Blob Storage. Many users look to the cloud to store binary data, such as photos, videos, and music. Cloud applications that need to support these types of data often store it using a Blob (Binary Large OBject) Storage mechanism, optimized for storing large amounts of data and often supporting outgoing mechanisms such as streaming. Volume Storage. When developers deploy applications to a PaaS environment, they often require access to durable data storage, to prevent data loss in the event that the application or underlying virtual machine is restarted. This is often referred to as volume storage. C. Development Experience Development and deployment to a PaaS environment is normally controlled and initiated through the Integrated Development Environment (IDE). The IDE is used to create new projects, write code, and deploy to the cloud environment. This is normally performed in conjunction with a Web based portal. In addition, many PaaS environments include the ability to run a local version of the cloud known as a local development environment. This ensures that the application will work correctly when deployed in the cloud (e.g. security restrictions) without having to actually deploy to the cloud, and therefore potentially running up costs up during the development. D. Security If vendors are going to attract organizations to move their business applications to a PaaS environment, demonstrating security for that environment is paramount. Security concerns for many organizations include: Physical Security. Does the cloud datacenter conform to security standards such as SAS70 Type II compliance? What are the procedures in place to protect applications from other deployed applications and employees? Access Control. Can the application be restricted to a certain number of users or groups? Can access control lists be applied on the data? Transport Security. How is the data and network secured between users of the application and the application running in the data center? Data Security. How is the data protected when stored in the PaaS environment? What are the encryption techniques? How is integrity of the data maintained? On-premise Connections. Does the PaaS vendor offer any solution for creating a VPN between applications in the cloud and applications running in an on-premise data center? E. Identity Moving applications from on-premise locations to the cloud often results in challenges with managing user identities. Few organizations want to expose their identity environment externally, yet at the same time many organizations don t want to deal with the management and security concerns of multiple accounts for their employees. To be successful, PaaS vendors must provide an identity solution that enables secure access to applications, with federation options to other identity 2028 MIPRO 2012/GLGPS

3 stores. When looking at federated identity solutions today, we often find one of two configurations: IV. Federation with on-premise. Allows organizations to use their on-premise credentials (for example, Active Directory) to access applications in the cloud. Federation with other Online services. Allows users to use the same credentials between multiple online services for example, the same username and password between hosted (a SaaS service) and an application deployed in a PaaS environment. DECISION FRAMEWORK FOR ARCHITECTURE SCENARIO TO BE APPLIED Regardless of number of possible scenarios that can be used to define the problem and thus apply architecture scenario that will be built on providers cloud computing infrastructure, there is final number of components that could be used to deliver such a solution. There are four general groups of components and each group has one or two entities that can be used. Some entities can produce more than one instance increasing the capabilities of specific component group. A. Component Group: User (Figure 1.) This component group hosts basic workloads that most of government applications need to have. This group also defines what kind of interface will be used to communicate with PaaS solution: Figure 1. Component group: USER Web Browser (requirement that they need to be accessible by browser interface on different computing platforms) imply that application should be built on three tier or two tier model hosed on providers cloud that enables scalability and availability, Mobile Browser (requirement that application needs to be accessible through mobile devices) imply that users will use variety of mobile devices that require specific formatting of data and end user elements to enable limited interaction with the end user, Managed Application (requirement that application will be built using managed code and hosted on PaaS platform if that is supported by the platform) imply that we need to use the PaaS platform that supports chosen managed language and/or can enable execution in native environment (without virtualization of the code). B. Component Group: Compute (Figure 2.) This component group hosts computing resources that are used to execute application in PaaS environment. This is usually highly scalable environment and has local components that enable some basic scenarios for execution: Web Role (page) (requirement that application communicate with environment through web interface and generate read/write pages that communicate the information) imply that we will implement standard HTTP based services that generate pages using different execution environments depending on operating system and services below, Web Role (service) (requirement that we have externally published web services that are accessible by other, third party web services who can relate and communicate the requests for services) imply that we need to build those services implementing standard WS* design (or other applicable) that can expose that services externally, Worker Role (requirement that we have internally published web services that are accessible by Web Roles, web services which can relate and communicate the requests for services) imply that we need to build those services implementing standard WS* design (or other applicable) that can expose that services internally, Figure 2. Component group: COMPUTE Table Storage Service (requirement that we need a storage to temporarily store processed data without need for full persistence of the data) imply that we need to enable mechanisms that will store processed information for single request / session in local storage and that that data can be purged after the request / session terminates, Blob Storage Service (requirement that we need a storage and handling mechanism to temporarily store large quantities of binary data that represents different information streams) imply that we need to enable mechanisms that will store processed information here in large quantities for single request / session in local storage and that that data can be purged after the request / session terminates, MIPRO 2012/GLGPS 2029

4 Cache Service (requirement that we need a local cache mechanism that will enable reuse of the data in multiple requests) imply that we need to enable mechanisms that will store information that needs to be accessed frequently and that we know it will not be changed over the specific period of time, Queue Service (requirement that we must handle specific requests and objects in specific order, synchronously or asynchronously) imply that we need to enable mechanisms that will track the order, execution and release of specific tasks in specific execution timeframe. C. Component Group: Database (Figure 3.) This component group hosts resources that are used to persist the data used in the execution in the storage where that data can be manipulated in the number of ways: Figure 3. Component group: DATABASE Application Data (requirement that we need permanent storage for the information objects) imply that we need to enable / use relational, object, hierarchical or integrated data storage model that will persist our data for a specified timeframe, Data Services (requirement that we need web services implementation that will enable services to service communication and exchange of persisted data) imply that we need to enable / build WS* standard based services that will open the persisted data through web services and publish the integration interface in defined services catalog, Business Intelligence Services (requirement that we need to implement number of services that will perform an analysis and return an insights on the raw persisted data) imply that we need to enable framework that will load, transform and analyze the persisted data in such a manner that it becomes more understandable and enable additional view on persisted data. D. Component Group: Fabric (Figure 4.) Figure 4. Component group: FABRIC This component group is one of the most interesting in any PaaS scenario, given the fact that there is an requirement that some of the applications implemented in the cloud must be connected and exchange the data with on premise implementations. For that, we need to implement a number of new services that will enable enterprise style application and data delivery: Connection Bindings (requirement that we need a connection mechanisms to enable different technology protocols to connect to application instance) imply that we need to build a endpoints where web services will connect to, Identities and Roles (requirement that we need to use models for managing user identities and their roles that will be used in the application and environment) imply that we need to implement security mechanisms that will enable identity management and use of these through roles that will use the application, Services Bus (requirement that we need to enable connections between internal applications but also internal and external applications and services) imply usage of service bus mechanism to uniformly access and share services and data through the platform. V. TYPICAL ARCHITECTURE SCENARIOS IN THE COLUD Depending on the component groups that are required by the PaaS applications, we can define number of typical applications architectures and patterns that will be used to build the application itself. To build applications that will maximize benefits, application provider must apply Cloud application design patterns to build systems that exhibit parallelism, multitenancy, autonomy, distributed interactions, declarative definitions, separation of concerns, and federation. Cloud applications are not simply web applications deployed on external provider infrastructure. Cloud applications represent an evolution of the application model away from sequential processing, synchronous interactions, shared resources, and static clusters. There are some core issues that development teams should look at while architecting for the cloud: Manage resource capacity to ensure consumer demand is satisfied while maximizing resource utilization Scale workload processing and increase performance while minimizing infrastructure spend Allocate, provision, monitor, manage, and administer resources across multiple tenants Operation s desire to right-size the infrastructure. Is the application architecture flexible enough to deploy on any topology while meeting deterministic performance requirements? Depending on the application model and scenario, there are number of similar architecture questions that drive final decision on what type of architecture should be applied for a specific government application scenario MIPRO 2012/GLGPS

5 A. Application Pattern: Portal offering solutions in a frictionless manner with lower costs to the end customers. Typical architecture in this category will follow the traditional 3-tier model with front end-middle tier-backend database; this kind of an application fits well with the growth pattern scenario; the application can be run as single tenant or multi-tenant where a multi-tenant application will have additional benefit of cost optimizations for running the application. C. Application Pattern: Massive Computational Needs (Parallel Computing) Figure 5. Application Pattern: Government Portal used for high scalability and availability of the services and applications Host traditional Web apps and interactive apps that compose two or more data sources and services. These include traditional hosted Web applications, emerging composed applications that may utilize two or more data sources and services. These applications need automatic scale-out and scale-down capabilities. An application like Government Citizes Services Provider is a good example. In such scenarios the organization may be a government agency that wants to spend little capital on infrastructure while being able to handle increasing demand. Or suppose the application s load will vary significantly, with occasional spikes in the midst of long periods of lower usage. An online form for specific government service site might display this pattern, for example, as might news information sites with occasional important stories, sites that are used mostly at certain times of day, and others. B. Application Pattern: Transactional Line of Business Figure 6. Application Pattern: Transactional Line of Business used for high availablity, 24 x 7, of the services and applications New applications are trying to continuously innovate and bring feature rich applications to their user base while continually building to differentiate from other and Figure 7. Application Pattern: Massive Computational Needs (Parallel Computing), where we need a high number of parallel computational tasks delivered usualy by worker roles Large-scale parallel execution of compute tasks. Normally these tasks execute for a short period of time utilizing more compute and storage resources. There are the parallel computing applications that need to perform multiple tasks in parallel so that a huge project can be executed in a short period of time. There are plenty of examples of this: rendering situational awareness on the battlefield, new drug development in a pharmaceutical company, financial modeling at a government agency, and more. While it s possible to maintain a large cluster of machines to meet this occasional need, it s also expensive. Cloud computing can instead provide these resources as needed, offering something like an on-demand supercomputer. Again, paying for the one-time-only large capacity that cloud computing can provide is a costeffective solution. D. Application Pattern: Analytical Services Large-scale parallel Analytical processing executes various analytical and data mining algorithms over the same data again and again. There are lots of situations where Web-accessible software also needs to initiate work that runs in the background, independently from the request/response part of the application. Large-scale parallel Analytical processing executes various analytical and data mining algorithms over the same data again and again. MIPRO 2012/GLGPS 2031

6 E. Application Pattern: Building Block Services A building block service is an example of a cloud component/service which fills a gap within the platform. Consider a cloud provider which provides monitoring data for services running on its cloud and applications can leverage to automatically scale by increasing or decreasing the number of instances for a particular scale unit within the application. Now every customer could use the monitoring APIs within their application and build this functionality or an customer could build this functionality as a component that could be leveraged by other customers to scale their solution. This would be a canonical example of a building block service which by itself has no use or function but once employed within another service can provide significant value. F. Application Pattern: Collaboration and Data Exchange Figure 9. Application Pattern: Software + Services that extend existing on premise infrastructure through services built on cloud computing governments have datasets which they could potentially license to customers: for example geographical shape files, digital renderers shared with production houses. In such scenarios the government is publishing data to services consumer so that he can use it in any specific way. I. Application Pattern: Business Inteligence and Reporting Another application pattern involves providing business intelligence as a service. With the advent of data, the ability to provide mining and intelligence on specific datasets is becoming increasingly important for companies to remain competitive and build optimization in their manufacturing, selling and marketing processes. Figure 8. Application Pattern: Collaboration and Data Exchange, we are opening internal interfaces to access the data through web services to enable new scenarios Service / data sharing between partners and customers: Tis application pattern can have numerous uses such as multi-enterprise integration, B2B & e-commerce applications; supply chain management, health and life sciences and domain specific services. G. Application Pattern: Software + Services Software + Services represent an industry shift towards a design approach that is neither exclusively software-centric nor browser-centric. By deeply and genuinely combining the best aspects of software with the best aspects of cloud-based services, we can deliver more compelling solutions for consumers, developers and businesses. H. Application Pattern: Data Provider This is the way for the Government to monetize information as a service, if that is feasible for the Government. There are numerous examples where VI. CONLUSION With immediate, affordable access to high-power computing resources, organizations can bring to market innovative products faster and more cheaply than ever before. The software economy will particularly benefit because developers everywhere can participate in the global IT market, regardless of the local technology industry infrastructure. There are number of architecture patterns that can be applied to the effort of building of government or any other application or services. Understanding the requirements of specific end customer but also the capabilities of the services provider, lead to a specific architecture pattern that can be used in building desired solution. REFERENCES [1] National Institute of Standards and Technology, A NIST Definition of Cloud Computing, [2] David Mitchell Smith, "Hype Cycle for Cloud Computing", Gartner Inc., MIPRO 2012/GLGPS