The foundation for most of the Oracle Public Cloud Platform services is the Java Cloud Service (JCS) that itself is powered by WebLogic Server. The same WebLogic that Oracle customers use as underpinning for their middleware platforms and business applications, either on traditional infrastructure, on the Exalogic engineered system or some form of Private Cloud set up.
It is extremely important for Oracle’s success as a cloud vendor that WebLogic Server satisfies a number of requirements:
· high density (note: density is the word used to indicate smarter use of resources. This applies both to physical system resources in your computer as well as to human resources and the effort they have to make for administration and ops purposes. Multi-tenancy is one approach to achieving higher density. It allows for more reuse and sharing across applications than is currently the case)
· dynamic scalability (flexible horizontal scale out and in, depending on the actual workload)
· continuous availability
· portability of workloads
· automated (or at least automatable) operations
Oracle released WebLogic Server 12.2.1 in the second half of October – a release it calls “the most important [release] in a decade”, exactly because it addresses these requirements. And, in addition to Oracle, all of us benefit from these [public and private] cloud enabling advancements.
High Density and Multitenancy
Higher density means running more workload per unit of physical resources – CPU plus memory – and more applications per single WLS domain. This saves on hardware, saves on human resources and potentially (for customers) saves on licenses. It is the same story for WebLogic as it is for the Oracle Database. And the solution is remarkably similar too: Oracle Database 12c introduced the Pluggable Database or PDB as the isolated, pluggable & portable unit of single tenant workloads. WebLogic 12.2.1 has a partition as the PDB’s counterpart.
Partition is a first-class citizen, that lives in a domain under a managed server. Partitions are isolated and have their own physical resources assigned to them CPU , memory and I/O. Internal operations at the JVM level such as heap management and garbage collection will be performed per partition. Start time of the partition is far less than the startup time of a managed server.
Partitions are isolated from one another. A partition can contain applications as well as Java EE constructs such as a dedicated JNDI, Security Realm, JMS topics and queues as well as JDBC data sources and other configuration items. Coherence Caches can both be private or shared. WebLogic partitions can also share some global resources, can be individually stopped and started and can also be exported and imported. A WebLogic partition with running applications on premises can be exported and imported into the Java Cloud Service or any other WebLogic domain.
With consolidation based on partitions, Oracle expects the number of WebLogic domains to be reduced drastically into far fewer domains (up to 10x) that will use partitions as a way to organize the applications running within the domain. As with PDBs, you will get a single partition included in all WLS editions; to have multiple partitions requires a special license; the extra cost of that license should be justified not only by the increased ease of operations and lower hardware costs but also by the decrease in the number of CPUs for which WebLogic would have to be licensed without consolidation. Oracle suggests that CAPEX can be decreased with 66% and OPEX with 25%.
Some examples of multitenancy configuration:
Partition Resource Management
WebLogic Server and JDK engineers collaborated on changes to both the JDK and the application server to deliver new capabilities that provide protection against resource-hogging applications. Resource managers can be associated with partitions to specify resource policy on the petition. These can for example trigger a restart of the partition when more memory is required than has been assigned to the partition. speakers and out of memory error will resolve it in a more elegant way. Resource management policies can be defined on the following resources: Heap Retained, CPU Utilization and Open File Descriptors (due to I/O, Sockets and so on). Policy configurations could be defined at the domain level and reused across multiple pluggable Partitions, or they can be defined unique to a Partition. Policies can also be dynamically reconfigured without restart of the Partition.
A system administrator can specify specific recourse actions to be taken when the policies are violated. A policy could either be created as one of the following two types: fair share: specify “shares” of a bounded-size resource for a Partition – WebLogic then ensures that this resource is shared effectively (yet fairly) by competing consumers- and trigger – “take a recourse action when a Partition crosses a threshold regarding resource usage”. When a trigger is breached, a system administrator may want to react to that by automatically taking certain recourse actions in response. The following actions are available out of the box with WebLogic: notify, slow [the partition down in consuming resources], fail [reject requests for the resource] and stop [shutdown the partition].
Resource Consumption Management leverages resource management support in Oracle JDK 8u40 and the G1 Garbage Collector. Special JVM arguments have to be passed when starting a JVM to enable these features.
Portability of Workloads
Almost as a side effect of introducing the partition for multitenancy, came the portability bonus: A WebLogic partition with running applications can be exported and imported from any WebLogic instance (including the Java Cloud Service) to any WLS domain, including JCS. After the import of the partition, the target domain is primed with the applications and the required configuration, ready to go. This means lift & shift of workloads at the partition level. This is quite similar – yet more specific – to the kind of portability containerization with for example Docker brings for general workloads at Linux level. Note that a 12.1.x or even 11g domain can be exported and imported as a 12.2.1 partition, next to other partitions in a WebLogic 12c domain.
WebLogic 12c is certified to run on Docker. This means that a Docker Container can be built with WebLogic Server 12c running inside it, applications can be deployed and resources configured; the Docker Container is to all intents and purposes a full blown if virtual server. This container can be shutdown, turned into an image and shipped to any Docker engine anywhere in the world where it can be started, just like that. Many public cloud vendors have support for running Docker containers, as does the Oracle public cloud. Through Docker, portability of WebLogic [workloads] has never been greater. What the exact license conditions are for running WebLogic inside Docker containers, I am not quite sure. You may just have to confer with your local Oracle Sales representative – although it probably boils down to the number of CPUs in the underlying OVM or physical server.
Note that Oracle has published scripts on GitHub to build a Docker container with a WebLogic 12c Domain. It does not publicly make ready-to-run images available.
Dynamic Scalability
The capacity of the WebLogic cluster should dynamically – or better yet: elastically – scale with the workload. If the number of requests being handled increases, more nodes should be added to the cluster and vice versa, nodes can be stopped with the load decreases. WebLogic 12.2.1 does this kind of dynamic scaling- extending the functionality of dynamic clusters first introduced in release 12.1.2.
Based on predefined rules that take capacity, demand and schedules into account, WebLogic can automatically scale up (or out) and down. Some metrics that weigh in: Throughput (requests/second), JVM Free heap percentage, Process CPU Load, Pending user requests, Idle threads count, Thread pool queue length. Additionally, WLDF provides some “generic” Smart Rules to allow you to create policies based on your own JMX-based metrics.
REST APIs are available to explicitly and easily start or stop a number of managed servers – all based on the same template. Note that changes in the cluster are communicated to Oracle Traffic Director (OTD) in order to properly route requests and balance the workload.
Also see this blog article: https://blogs.oracle.com/WebLogicServer/entry/elasticity_for_dynamic_clusters .
Continuous Availability
Cloud providers are expected to deliver superior service levels, reflected in various non-functional qualities including scalability, performance and availability. Continuous Availability is the marketing people’s label for a number of features in WebLogic 12.2.1 around this latter service aspect: to reduce application downtime.
Zero down time patching (ZDT) is one aspect: Zero Downtime Patching allows you to rollout distributed patches to multiple clusters or to your entire domain with a single command. All without causing any service outages or loss of session data for the end-user.
By automating the process of patching, the amount of human input required is reduced [less chance of errors], and the little input still provided can be verified before making any changes. This will have a huge impact on the consistency and reliability of the process, and it will also greatly improve the efficiency of the process.
The process is resilient in that it can retry steps when there are errors, it can pause for problem resolution and resume where it left off, or if desired, it can revert the entire environment back to its original state.
ZDT takes advantage of existing clustering technology combined with an Oracle Traffic Director (OTD) load balancer, to take individual nodes offline to be updated one at a time.The load balancer is instructed to redirect requests to active nodes. Using advanced techniques for preserving active sessions, the end-user will never even know the patching is taking place. ZDT can also be used for updating the Java version used by servers, and even for doing some upgrades to running applications, all without service downtime for the end-user.
New in Oracle WebLogic Server 12.2.1 is an end to end solution for building Multi Data Center architectures, available as an extra (cost) option: WebLogic Server Continuous Availability for Multi Data Center Deployments. Applications running in multi data center environments can run in Active-Active and Active-Active Stretch Cluster environments continuously. When one site fails the other site will recover work for the failed site. Automated data site failover kicks in for failover or switchover events, reducing human effort and risk of human errors. Oracle Site Guard is the tool that provides end-to-end Disaster Recovery automation. It automates failover or switchover by starting stopping site components in a predetermined order, running scripts and post failover checks. Oracle Site Guard minimizes down time and human error during failover or switchover. Oracle Traffic Director can be highly available either in Active-Active or Active-Passive mode.
Replication of state across multi-data center deployment is crucial for disaster recovery. State in Coherence memory grid can be replicated across even remote locations using Coherence Federated Caching: a mechanism that distributes Coherence updates across distributed geographical sites with conflict resolution. The modes of replication are Active-Active with data being continuously replicated and providing applications access to their local cached data, Active-Passive with the passive site serving as backup of the active site, and Hub-Spoke where the Hub replicates the cache data to distributed Spokes.
On a related topic: automated transaction recovery in Active-Active Maximum Availability Architectures is supported through WebLogic Cross Domain XA Recovery: the ability to automatically recover transactions in a domain on the surviving site when a WebLogic Server domain fails in one site or the entire site comes down. This involves TLOG replication across sites for automated recovery of a crashed site.
Another feature that is part of continuous availability: WebLogic Multitenant Live Partition Migration. In Multitenant environments Live Partition Migration is the ability to move running partitions and resource groups from one cluster to another, without impacting application users. During upgrade, load balancing, or imminent failure, partitions can be migrated with zero impact to applications.
Automated (or at least automatable) operations
REST APIs are available in WebLogic 12.2.1 for all (or almost all) administrative activities. Anything done previously through WLST – or the Console – can now also be done through REST over HTTP. This has quite a few benefits: the client used for performing the actions does not need a JVM nor does it need a JMX based (t3 protocol) connection to the WebLogic domain – http suffices. Generic REST clients are plentiful and custom clients are easy to develop; I would expect that many Oracle partners flock to the opportunity of providing tailored consoles on top of these APIs. The new Enterprise Manager 13c is an example of such a new console from Oracle itself.
The WLS REST APIs are largely dynamically generated, support synchronous and asynchronous execution of operations and apply to both admin and managed servers. Many REST based interactions are faster (5 to 10 times) than their WLST equivalent– because they execute consolidated (coarse grained) operations in one go.
In addition to these APIs, Oracle offers Enterprise Manager Cloud Control (EMC2) as the consolidated console across all Database and Fusion Middleware components – and across public cloud, private cloud and traditional on premises systems (the single pane of glass). From Enterprise Manager, many DevOps and IT Ops activities can be executed, for various components in the stack, including WebLogic.
Some new or improved areas in EM 13c include:
· Auditing – record an audit trail (and provide searchable access to super administrators) of WLS domain activities (login, logout, update, invoke)
· Drift Management & Continuous Compliance – ensure standards are defined and maintained; this mechanism helps provide insight in deviations in actual configurations from predefined standards, using automated policy violation notifications. It is based on the compliance framework and configuration comparison capabilities. New STIG (Security Technical Implementation Guidelines) rules are included for WLS 12c.
· Log Monitoring and Viewing: off line mode to access log files regardless of whether WLS domain is up or down; consolidate log files to single, central domain
· Coherence Management: HeatMap view to inspect nodes, caches, services and host along several dimensions and metrics; support for multitenancy clusters; Coherence Log Viewer; automated removal of down members
EM 13c offers best practices for managing targets such as WebLogic Domains and the FMW components running on them. In addition to descriptions of guidelines, this feature offers direct links to the relevant features in the EM 13c console as well as to supporting resources such as instruction videos.
The Java Workload Explorer (JWE) in EM 12c and beyond is the primary interface to diagnostics data from the JVMs. This interface offers deep insight in JVM activity, per thread and per request handled. Details are tagged with ECID and session user, and report on many elements including SQL statements and call stack. The instrumentation that feeds JWE can be enabled and configured dynamically, without restarting servers.
Developer Productivity
In addition to the many features for scalability, ease of administration, availability and higher density, WebLogic also continues to evolve in terms of development productivity and functional richness. With release 12.2.1, at last Java EE 7 is now fully supported – which means for example support for JMS 2.0, EJB 3.1, CDI 1.1, EL 3.0, [Java] Batch.
Also like release 12.1.3, WebLogic 12.2.1 is certified for Java SE 8. Though it is not there yet, WebLogic 12.2.1 will soon (Spring 2016?) also be available on the Oracle Cloud – representing full Java EE 7 commercial support on the cloud from Oracle.
For developers (and anyone else for that matter), there is a quick installer that is relatively light weight at 200 MB. This installer produces an installation that can be patched. The deployment performance is improved, as is the IDE support in Oracle Enterprise Pack for Eclipse, Oracle JDeveloper and Oracle NetBeans. The Java SE 8 features – lambdas and streams – have been implemented on Coherence; it makes it possible in a very simple way to execute large-scale operations on a multi-node Coherence grid using standard Java SE operations.
The public Oracle Maven Repository (at http://maven.oracle.com/) has been updated for 12.2.1.
Down the road[map]
The main themes for WebLogic Server 12.2.2 – to be expected in the Fall of 2016 – are:
· more extended multitenancy, across the full WLS & Coherence suite, including additional partition administration options such as merge partitions, split partitions, clone partitions and perhaps find differences between partitions; maybe on line ‘lift & shift’ to and from JCS; also improvements in Garbage Collection and Resource Consumption Management
· adoption of multitenancy in JCS and across FMW (SOA Suite, WebCenter, etc.)
· continuous availability enhancements – improvements in Zero Down Time (ZDT) Patching, Live Partition Migration, JTA (for transaction recovery)
· integration with the Identity Management Cloud Service
· more cloud optimizations – support for HTTP/2, Cluster transparency with JMS, further Docker optimization, Maven and Gradle plugins, and perhaps including easy integration with Management Cloud Service (for performance monitoring and log analytics)
· security
· compatibility/usability
· perhaps support for some early Java EE 8 APIs (for example JCache)
Saying that 12.2.2 is coming in the Fall of 2016 is not quite correct as Oracle will adopt a cloud release cycle – which means that WebLogic on the Cloud (JCS) will start evolving in smaller, more frequent (quarterly) steps than the on premises edition. So some of these updates will come in JCS long before 12.2.2 is available on premises.
Lift Off – PaaS Foundation Cloud Services
The Java Cloud Service (JCS) is one of the core PaaS services –along with DBaaS. Many other PaaS offerings use JCS internally (such as ICS, PCS, DCS, SOA CS) and several other FMW products are certified on JCS (for example BPM Suite, WC Portal, WC Sites). JCS is powered by WebLogic and Coherence. At the time of writing (end of 2015) JCS is based on WebLogic 12.1.3. Adoption of 12.2.1 is indicated for early Spring of 2016.
Recent new developments around JCS include high availability with Oracle RAC Integration with Exadata Cloud, easy (“one click”) vertical and horizontal scalability, agility for Testing/Staging with Instance Cloning, resiliency with standby disaster recovery in addition to the single pane of glass – Enterprise Manager – for management across on premises and cloud.
JCS – apart from being the foundation for many PaaS services, is also a PaaS service in its own right, for running Java EE workloads, such as ADF web application and pure Java EE web services and integration solutions.
Oracle also announced PaaS services for running different types of workloads:
· Node for running JavaScript workloads; the Node driver for Oracle Database can be leveraged to interact with the Oracle Database Cloud Service
· Java SE for running Java SE 7 or SE 8 applications running on or with Tomcat, Jersey, Jetty, Play and other libraries and frameworks; JVM-based languages like JRuby, Jython, and Closure can be used as well. This service includes Java Flight Recorder for JVM monitoring and tuning.
· (shortly) other languages like PHP, Ruby, Python and others
These new services are flavors of the Application Container Cloud Service. This is described by Oracle as a “Polyglot Platform for Lightweight Applications Running on Docker Infrastructure”, that can be used to implement a cross language micro services architecture. Oracle positions this service against AWS, IBM Bluemix, RedHat OpenShift, Pivotal Cloud Foundry, Heroku, Microsoft Azure.
The Application Container Cloud runs Oracle Linux in Docker containers, with the user selecting the amount of RAM per application and the usage charged in GB hours. The underlying Docker environment is not exposed directly; elastic scaling is powered by Docker. Scaling rules can be defined based on maximum response times; this means for example that you contains will be started as soon as the response time starts to cross a certain threshold. A load balancer ensures that traffic is distributed across the container instances. The containers have ephemeral disks—permanent storage has to be engaged through database or storage service.
Containers can be based on images defined and maintained by Oracle (the application container cloud service) or on custom application images (the separately announced Docker Cloud Service).
Service bindings can be created to wire application containers to other Oracle Public cloud services in the same identity domain, including database, messaging and storage as well as other application containers. Developer Cloud Service integrates with Application Container Cloud Service for continuous integration and delivery services to support DevOps environments.
Note that in addition to UIs, REST APIs are available for administrative queries and actions.
See this movie for a two minute visual introduction to the Application Container Cloud Service.
Oracle also announced a partnership with Bitnami. Bitnami is a library of over 130 popular server applications and development environments – from WAMP, MAMP, LAMP and Ruby, to collaboration tools like WordPress, Drupal, Ghost, and Roller – that can be installed with one click, either in your laptop, in a virtual machine or hosted in the cloud.
Bitnami offers assurance that applications come from a trusted source, are patched, secured and updated; it takes care of compiling and configuring the applications and all of their dependencies such as third-party libraries, language runtimes and databases. Part of the use case for Bitnami (and Application Container CS) described by Oracle: customers using one or more of Oracle’s PaaS services, but also need to hook that up with other things that don’t exist within the Oracle PaaS universe. A lot of those applications and bits of infrastructure do exist in the Bitnami application catalog,
Bitnami offers an easy-to-use Web management console for both Amazon Web Services (AWS), Azure and Google users and now Oracle Public Cloud as well. To launch Bitnami applications on the Oracle Application Container Cloud Service with a single click, go through the Bitnami Cloud Launchpad or the Oracle Cloud Marketplace. This combination of Bitnami and Oracle Public Cloud offers a one hour free trial for running a Bitnami application on the Oracle Public Cloud.
