This document discusses how a cloud native middleware platform can help solve issues with effective eGovernment systems. A cloud native platform provides an elastic, multi-tenant architecture that allows different government agencies to securely access shared services and data in the cloud. It also supports deploying common services for all agencies while allowing individual agencies to have their own unique processes and data. This type of platform enables central management of resources while giving individual agencies flexibility and isolation through tenant-level virtualization. It can help integrate scattered data repositories, enable transactions across agencies, and reduce costs through an on-demand, pay-per-use model.

1. Moving eGovernment
to the Cloud
Chintana Wilamuna
Senior Technical Lead
chintana@wso2.com

2. Open source software
• A license that legally give the right to,
– Run the program for any purpose
– Study and modify the program
– Redistribute the program (in modified and
unmodified states)
• Free software, OSS, FOSS, FLOSS
• Many licenses
– http://opensource.org/licenses/alphabetical

3. Why open source?
• Brings transparency
• Faster security fixes/patches
• Use of open standards
• Broad usage in many verticals
• Commercial support available
• Used in many business critical applications

4. Why open source in government?
• Transparency
– Not at the mercy of a proprietary vendor
• Detailed evaluation before using
– Evaluation of different aspects – functionality, security, extensibility
– Open forums for discussion, bug tracking, community
• No vendor lock-in
– Use of open standards, many providers of commercial support

5. Cloud computing
Cloud computing is a model for enabling ubiquitous,
convenient, on-demand network access to a shared
pool of configurable computing resources (e.g.,
networks, servers, storage, applications, and services)
that can be rapidly provisioned and released with
minimal management effort or service provider
interaction.
- National Institute of Standards and Technology (NIST – www.nist.gov)

6. Cloud computing characteristics
• On-demand self service
– CPU, storage, RAM - without an admin
• Broad network access
– Accessible over a network
• Resource pooling
– Accessibility through a multi-tenant model
• Rapid elasticity
• Measured service

7. Service models
• Software as a Service (SaaS)
– Application running on the cloud
– Accessed from web, mobile, native apps
• Platform as a Service (PaaS)
– Deploy applications into the cloud
– Provide libraries/frameworks/tools to build applications
• Infrastructure as a Service (IaaS)
– Provision fundamental computing resources; CPU, RAM, storage etc…
– Has control from the operating system to deployed apps

8. Deployment models
• Private cloud
• Community cloud
– Provisioned to be used by a specific community of consumers
• Public cloud
• Hybrid cloud
– Combination of two cloud infrastructures
– Technology enables data and application portability
– Used for cloud bursting

9. Issues – Effective eGovernment
• Collection of massive amounts of data
• Scattered in different data repositories
• Transactions spanning multiple agencies
• Intergovernmental data access
• High capital and operational expenditure
• Provisioning resources become cumbersome
• Ensure data integrity of disparate systems

10. Data collection
• Citizen data
• Documents needed for a specific function
– Loan approval
– Vehicle license renewal etc…
• Importance of having a single consistent set of
information about a citizen

11. Scattered repositories
• A citizen can belong to a single province
– The geographical area where he cast his vote
• Can have information scattered in different
provinces
• Ability to view information from a central
portal

12. Transactions with multiple agencies
• Refer/executing processes from another local
government agency (from another
province/state)
• Authorization model that can grant permission to
needed local agencies
How to solving these issues with a cloud native
middleware platform in an eGovernment solution?

13. Cloud Native Middleware
• Elastic (Uses the cloud efficiently)
– Scales up and down as needed
– Works with the underlying IaaS
• Self-service (in the hands of users)
– De-centralized creation and management of tenants
– Automated Governance across tenants
• Multi-tenant (Only costs when you use it)
– Virtual isolated instances with near zero incremental cost
– Implies you have a proper identity model
• Granularly Billed and Metered (pay for just what you use)
– Allocate costs to exactly who uses them
• Distributed/Dynamically Wired (works properly in the cloud)
– Supports deploying in a dynamically sized cluster
– Finds services across applications even when they move
• Incrementally Deployed and Tested (seamless live upgrades)
– Supports continuous update, side-by-side operation, in-place testing and
incremental production

14. WSO2 middleware stack

15. Flexible and agile

16. WSO2 Carbon

17. WSO2 Carbon

18. WSO2 Carbon

19. WSO2 Carbon

20. WSO2 Carbon

21. Cloud Native Middleware

22. Importance of multi-tenancy
• Every service can support multiple tenants in
the same container. A tenant is a local
government agency or can be a state.
– Higher efficiency, lower resources
– Can be split tenant per-VM using the MT-aware Load Balancer
• Isolation includes classloaders, code signing
and Java security policies
– Cross-tenant sharing is via the network (REST, SOAP, etc)
22

23. Importance of multi-tenancy cont.
• Every tenant has all services by default but
they can be turned off
• Central government deploying services that
are common to all states/local/provincial
agencies
• Provincial agencies can have their own
services/business processes
• Provincial offices work on their dataset

24. Importance of multi-tenancy cont.
• Central government can access the portal and
can have a holistic view of the entire system
• Can find out detailed statistics about the
operation of each local government agency
• If required a privileged user can perform
activities of a local agency. Governed by
authorization policies defined by the
provincial agency

25. Importance of multi-tenancy cont.
• Data and processes of a local agency is
isolated from another. Can grant selective
access via authorization policies (XACML)
• Flexibility of multi-tenant architecture – Ability
to have a common set of functions across all
local agencies and at the same time can have
specific services/processes as well

26. Architecture of the solution

27. Architecture of the solution
• LG – Local Government Agency
– Deployed
• Central operations
– Public cloud deployment by the central government
– All local/provincial agencies have a tenant in Stratos (e-LG1, e-LG2 etc)
– eGov apps runs under each tenant
– e-LGs are isolated from each other (both data and execution)

28. Architecture of the solution
• Some local agencies have good internet
connection
– e-LGn and e-LG(n-1)
– No local deployments
– Directly connects to central
– Application state and data for e-LG tenant in central cloud reflect the
latest state

29. Architecture of the solution
• Some local agencies does not have good
internet connection
– e-LG1 and e-LG2
– Applications/business processes deployed locally on-premise
– Applications deployed under the respective tenant in central for e-LG
is synced with the local deployment of e-LG when the connection is
available
– Application state and data on central reflect the last synced state
– Application state and data on e-LG local deployment always reflect the
latest state

30. References
• NIST cloud computing definition
– http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
• White paper: Moving eGovernment to the
Cloud
– http://wso2.com/whitepapers/moving-egovernment-to-the-cloud/

31. Questions?

32. Thank you!