BRISBANE, Queensland (October 05, 2015)—Rubicon Red, an Oracle Platinum partner, announced today it has formed a strategic partnership with AMIS, an Oracle Platinum Partner based in Netherlands focused on Oracle Fusion Middleware. The partnership will widen availability of Rubicon Red’s MyST, the industry-leading DevOps tool for Oracle Fusion Middleware, in Europe.
“Clients repeatedly tell us the most important element of the AMIS value proposition is that our deep technological insight in Oracle technology significantly lowers project risk and complexity based on our wealth of experience with Oracle FMW,” , Robbrecht van Amerongen ,Manager Continuous Delivery and Security practice at AMIS, said. “With the addition of MyST to our delivery capabilities, we can further reduce project risk and accelerate the overall project lifecycle. This allows our clients to capitalize on their investment in Oracle FMW faster and decrease the project risk more than previously expected.”
Manually provisioning Oracle Middleware environments, plus deployment of code is resource intensive and error-prone. Deployment errors result in many wasted months of effort, causing project delays, plus significantly increases the risk of major production issues, with associated financial and brand damage. MyST delivers automated platform provisioning and continuous delivery for Oracle Middleware, on-premise and on-cloud. Enabling users to deliver a consistent and reliable platform in minutes, NOT weeks or months. MyST is unique, being the only solution to combine concepts of “computer aided design” and “programmable Infrastructure” to automate the end-to-end process of designing and provisioning Oracle Middleware. With MyST, users model the required middleware infrastructure; which at the push of a button is provisioned by MyST. All with Zero Scripting!
As a result of the partnership, AMIS clients will now have access to MyST as well as the resources to assist with usage and knowledge transfer to the client team. With an average one-year ROI between 100 – 300 percent, AMIS clients can expect to see an immediate return on investment resulting from significantly reduced project complexity and risk. In addition, AMIS clients can benefit from faster and more frequent provisioning capabilities.
“DevOps and Cloud are gaining mainstream adoption as the preferred delivery and operating models for modern applications,” Matt Wright, Chief Technology Officer, Rubicon Red, said. “The partnership with AMIS, an internationally recognized thought leader in the delivery of Oracle Middleware solutions in Europe, will allow organizations to utilize MyST to be more responsive in delivering new Oracle Middleware solutions faster, cheaper and more frequently.”
About Rubicon Red Rubicon Red offers organizations a set of innovative and market leading cloud and consulting solutions for Oracle Fusion Middleware customers. An Oracle Platinum Partner and recognized global leader in Oracle Fusion Middleware, Rubicon Red delivers thought leadership, innovation and unrivaled expertise. Founded in 2009 by two former senior executives from Oracle product management, Rubicon Red is an Oracle Certified SOA and BPM Specialist, and has been awarded the Oracle Fusion Middleware Top Technical Champion APAC on multiple occasions. About AMIS AMIS helps organizations make optimal use of their investments in Oracle technology. AMIS is internationally recognized for its deep technological insight in Oracle technology. This knowledge is reflected in the presentations AMIS delivers at international conferences such as Oracle OpenWorld, JavaOne, DEVOXX and many other user conferences around the world and its well-read technology blog: http://technology.amis.nl. AMIS is an Oracle Platinum Partner and was awarded the Middleware Partner of the Year Award in 2011, 2013, 2014 and 2015. AMIS delivers advanced consulting in SOA, ADF, OSB and BPM and has a vast team of experts in this technology. The services of AMIS include architecture, infrastructure provisioning, application development, software build automation and deployment automation.
During the lifetime of a project, code will be built and promoted to various environments such as Development, System Integration and Test (SIT), User Acceptance and Test (UAT), Pre-Prod as it makes its journey to Production.
Specific testing is performed in each of these environments, with any defect resulting in the impacted code being modified to “hopefully” address the issue, and then re-start the journey from Development to Production. This route the deployments take is sometimes referred to as the "path to production".
What is rarely appreciated is that we are not just testing the code as we move it through each environment, but the release process of building, deploying and configuring the code, and the configuration of the infrastructure to run that code.
The problem with Configuration Drift
It is unfortunately all too common for each new release to fail the first time it is deployed to each environment, in many cases the deployment itself will fail due to configuration issues. In these cases, developers will often make a manual “quick fix” to complete the deployment process so that testing can begin.
This can quickly lead to small discrepancies between environments, such as disparities in the configuration of deployed SOA/BPM composites and OSB services, adapter configurations, WebLogic resources, or applied patches.
Issues caused by Configuration Drift are often the most difficult to diagnose and result in many wasted months of man effort to resolve
These discrepancies, referred to as configuration drift, often impact the behavior of the code and start to surface during testing or worse in production. Typically these issues are reported as code defects. The standard process to try and resolve any defect is to re-produce it in an earlier environment, so that the root cause can be diagnosed, a fix can be produced and validated before promoting to upstream environments.
But often we face a catch-22 scenario, where we cannot re-produce the issue in other environments due to the configuration differences! As a result, issues caused by Configuration Drift are often the most difficult to diagnose and result in many wasted months of man effort to resolve; resulting in project delays, cost blow out and missed milestones.
Worse still, if these issues surface in Production, it can result in all sorts of problems including security, performance and availability issues that can have a material impact on the business. For example, disaster recovery failures and HA system failures are frequently a result of configuration drift.
Minimize differences between Environments
To avoid this, we need to ensure that each environment in the software delivery pipeline should have an equivalent configuration to production.
The first step in enabling this is to start off with equivalent Oracle Middleware environments at all stages of the SDLC. This on its own can be virtually impossible to achieve when provisioning these environments manually.
Rubicon Red MyST allows users to fully automate the end-to-end process of designing and provisioning Oracle Middleware environments, on-premise and on-cloud. Enabling users to deliver a consistent and reliable platform in minutes, NOT weeks or months.
Central to MyST is the Platform Blueprint, which provides an abstraction layer over the underlying infrastructure, meaning that you can use the same Platform Blueprint to provision production-like environments to your staging environments.
A Platform Model is then used to capture all the environment-specific configuration information required to provision an instance of an Oracle Middleware platform into the selected environment. With this approach, we create a Platform Model for each staging environment, all based on the same Platform Blueprint.
The Platform Blueprint and Model are placed under version control, allowing us to treat configuration as code. This gives us the flexibility to provision a consistent middleware platform across all environments, as well as having the ability to roll forward / backward to a different version of the platform and hence eliminate the possibility of configuration drift.
Once we have automated the provisioning Next is to fully automate the build and deployment of code to those environments, as well as any additional configuration changes required to execute the code. Again with MyST, this is straight forward (see Automating the Build & Deployment of Oracle BPM and SOA Projects for further details).
Putting in place automated platform provisioning and continuous delivery for Oracle Middleware, will allow us to make significant progress towards preventing configuration drift. However whilst this addresses many of the root causes of configuration drift, it does not address all of them.
The reason for this, is each time we make a deployment to any environment, we are making changes to that environment, which means that it is no longer in-alignment with production. If the release passes, and the code gets successfully promoted through all the remaining stages and into production then this is not an issue. As eventually the same release will be promoted to production and our environments will be re-aligned.
But if the release fails, we will need to create a new release, in order to address the defects reported in the previously failed release.
As a result, what is deployed to any environment is the culmination of previous failed releases and configuration changes (i.e. releases that have not made it into production) plus the latest build. In addition it’s quite common when releases fail, for developers to make quick fixes outside the release process, so that testing can continue until the new release is available.
This leads to the environment becoming less like production each time we deploy a new build; causing configuration drift. This commonly leads to releases failing when promoted to the next environment, or worse still, when promoted into Production.
To prevent this, then prior to making the next release, we need to restore the environment back to its pre-deployment state, so that it is re-aligned with Production.
Typically, the easiest way to guarantee this is to tear down our middleware platform and re-provision it to a state consistent with production, prior to each release. This includes re-provisioning the Middleware environment from scratch, and then re-deploying the current version of applications that are deployed in production.
For our CI environment, where we are often making several releases a day, it’s not practical to re-provision the environment prior to every release. Rather, it is better to schedule a re-build of the CI environment nightly.
As we have already automated the provisioning of an environment, as well as the build and deployment of applications to an environment, then automating the re-provisioning of an environment is very straight forward.
As MyST integrates with popular Continuous Integration tools, including Jenkins, Hudson, TeamCity and Atlassian Bamboo, it is very easy to integrate the re-provisioning of an environment into our delivery pipeline.
An additional benefit of this approach is that it helps to encourage developer best practice when making configuration changes. As we have previously observed, deployments will often fail due to configuration issues. In these cases, developers will often make a manual “quick fix”; this will fix the release in that environment, but those changes are often forgotten, and the same issues are encountered at the next stage. Tearing down our middleware platform and re-provisioning will quickly discourage this unproductive behavior and encourage developers to make configuration changes as part of a controlled process.
Reduce Risk, Decrease Costs, and Speed Up Time to Market
Organizations are in a digital race, where the speed at which IT can reliably deliver new features and innovations is what sets them apart from their competition.
Eliminating configuration drift during the development of Oracle Middleware projects can significant reduce the amount of time wasted troubleshooting and resolving configuration issues, significantly reducing the overall project development time and cost, as well as significantly reduced the risk of a major issue at go live.
In short, the benefit of adopting these techniques as part of an overall Continuous Delivery strategy will provide the business with a strategic advantage in its ability to be more responsive in delivering new solutions faster, cheaper, and more often.
Rubicon Red is proud to announce success at this year’s Queensland AIIA iAwards, with Rubicon Red’s MyST software, taking out the New Product Category.This award further reinforces Rubicon Red’s commitment to thought leadership, innovation and expertise, and will see Rubicon Red’s MyST solution progress to the National iAwards event, scheduled for August 2015.The AIIA iAwards New Product award recognises an outstanding ICT product developed by an Australian organisation. The New Product must have moved on from the conceptual stage and into production and sales. The New Product category was judged against the following criteria
Quality Of Technology
MyST delivers a zero coding, 100% automated DevOps experience for Oracle Middleware. Launched in 2013, MyST has established a market leading position, with rapid adoption in Australia, and now the US, securing Fortune 200 and ASX200 customers.
About The iAwards
For over 20 years the iAwards has been recognising and celebrating the achievements and innovation made in ICT across all areas of the economy. The iAwards honours companies at the cutting edge of technology innovation and celebrates the up and coming innovators of the future.
The iAwards provides the platform to discover, recognise and reward ICT innovations that have the potential to, or are already significantly impacting the community. The iAwards are judged by the industry and provide recognition that extends across all sectors of the digital economy.
The goal of Continuous Delivery and DevOps is to help software development teams drive waste out of their process by simultaneously automating the process of software delivery and reducing the batch size of their work. This allows organizations to rapidly, reliably, and repeatedly deliver software enhancements faster, with less risk and less cost.
Continuous Integration (CI) is the practice of automatically building and testing a piece of software; either each time code is committed by a developer or in environments with a large number of small commits, or a long-running build on a regular scheduled basis.
Continuous Delivery (CD) goes a step further to automate the build, packaging, deployment, and regression testing, so that it can be released at any time into production.
Continuous deployment takes this another step further, in that code is automatically deployed into production, rather than when the business decides to release the code.
DevOps (development and operations) builds on Continuous Delivery and is used to mean a type of agile and collaborative relationship between Development and IT Operations. The goal of DevOps is to change and improve the relationship between Development and Operations by advocating better communication and collaboration to enable the business to deploy features into production quickly, with minimum risk and to detect and quickly correct problems when they do occur, without disrupting other services.
Work in Small Batches
The batch size is the unit at which code under development is promoted between stages, such as SIT, UAT, and Pre-Prod, in the development process.
Under a traditional development process, the code from multiple developers working for weeks or months is batched up and integrated together. During the integration process, numerous defects will be surfaced. Some will be the result of a lack of unit testing, but many will be down to invalid assumptions about the various pieces of code developed in isolation and how they will work together as part of the overall solution.
This is especially the case for Oracle SOA and BPM projects, which involve integrating multiple systems together. It is a common mistake for all parties to agree on the interfaces between the systems and then go off and code independently, with each party making invalid assumptions about how the other systems will behave.
The bigger the batch, the longer these assumptions remain undiscovered, and the greater the number of defects in the batch. A significant amount of the time taken to fix a defect is actually spent trying to isolate the problem and determine the root cause, rather than fixing the problem.
The issue with a big batch is that many of the defects are interwoven, and that the volume of code that needs be analyzed to troubleshoot a defect is greater. In addition, code based on invalid assumptions can often require significant re-work once these invalid assumptions are discovered; the longer these remain undiscovered, the greater the amount of invalid code written and the greater the amount of re-work required. As a result, the amount of time taken to identify and fix defects increases exponentially with the batch size.
Continuous delivery promotes the use of small batches, where new features are developed incrementally and promoted into the various test environments on a regular and frequent basis.
Small batches mean problems are caught immediately and instantly localized, making it far simpler to identify the root cause and fix. In the case of invalid assumptions, these are discovered far earlier in the process, when they are cheap to fix, and results in higher-quality software.
Software components that are implemented in isolation are full of assumptions about the other components with which they will be integrated. The sooner we can identify these assumptions, the smaller the impact and the associated waste will be. Small batches enable us to integrate these components earlier in their respective development lifecycles, and thus reduce the risk and overall impact on the project.
Process for Releasing / Deploying Software MUST be Repeatable and Reliable
To enable the development team to work in small batches, we need to remove the waste in the current build and deployment process. This requires that the process for releasing/deploying software MUST be efficient, repeatable, and reliable.
This is achieved by automating each step in the software delivery process, as manual steps will quickly get in the way, become a bottleneck, or risk introducing unintended variation. This means automating the build and deployment of code, the provisioning of middleware environments, plus the testing of code.
Minimise Differences Between Environments
A common anti-pattern is deploying to a production-like environment only after development is complete.
It is unfortunately all too common for solutions to fail on first deployment to any environment. Small inconsistencies between environments, such as disparities in the configuration of deployed SOA/BPM composites and OSB services, adapter configurations, WebLogic resources, or applied patches can cause issues with deployed code that are difficult to diagnose and rectify.
This means that there can be almost no confidence that a particular software release will work successfully if it has never been tested in a production-like environments.
To avoid this, deployment should always be to production-like environments. Each time we make a deployment to any environment, we are making changes to that environment, which means that it is no longer in-alignment with production. If the release passes, and the code gets promoted through to the next stage and into production then that is not an issue. But if the release fails, we need to restore the environment back to its pre-deployment state, prior to deploying the next release.
Build Quality In
W. Edwards Deming, in his famous management guideline, stated:
"Cease dependence on mass inspection to achieve quality and improve the process and build quality into the product in the first place”.
This means ensuring improvement and quality assurance at every step of the value stream instead of testing just the final product for compliance to requirement.
For software, it translates to writing automated tests at multiple levels (unit, component, and acceptance) and automating their execution as part of the build – test – deployment pipeline.
This way, whenever a commit happens (which is a change being made to either of the application, its configuration, or the environment and software stack that it runs on), an instance of the pipeline runs and so do the automated tests that verify / validate business expectations in form of test cases.
Applying Continuous Delivery in the development of Oracle Middleware projects can deliver significant reductions in development time and costs.
Today every business is a digital business, where the value that the business delivers to its customers, either through its products and / or services is increasingly derived from the software “systems” that underpins them. The end service delivered to the customer is not performed by a single system; but rather a patchwork of applications, each one performing a particular business function. Oracle Middleware components, such as the Oracle BPM Suite and Oracle SOA Suite, provide the application platform to combine these business apps, like puzzle pieces, into an integrated solution in order to deliver a seamless and unified experience to the customer.
Organizations are in a digital race, where the speed at which IT can reliably deliver new features and innovations is what sets them apart from their competition. Yet in most organizations, IT projects are failing to deliver, either on-time or on-budget.
"Studies have shown that software specialists spend about 40 to 50 percent of their time on avoidable rework rather than on what they call value-added work, which is basically work that's done right the first time..." - Robert Charette, IEEE Spectrum, Sept. 2005
The Need to Eliminate Waste
Removing waste in software development can result in significant cost savings, but more importantly, it can reduce the length of the software development lifecycle, allowing businesses to deliver solutions faster to market. Improving an organisations innovation, competitiveness, and responsiveness in the marketplace.
Within SOA and BPM projects, there are many forms of waste, but some of the biggest causes of waste include:
Manual Build and Deployment of Code is Error Prone
Test Teams Idle
Defects Discovered Late in Delivery
Manual Build and Deployment of Code is Error Prone
Manually building and deploying code is a resource intensive and highly error prone process; ask anyone to perform a task tens, hundreds, or even thousands of times and you will find that there are inconsistencies / errors; this is further compounded by the fact that in most organizations there are different individuals and teams performing these tasks in each environment.
An incorrect deployment is one of the most common causes of issues when promoting code into a staging environment. Small errors, such as misconfiguration of a middleware component, can cause issues that are difficult to diagnose and rectify, often requiring many days / weeks of man effort to resolve. As a result, we’re often left with a situation where deployed code fails to work, with the all too familiar expression;
“Well, it worked in my environment!”
These are not one-off issues, but rather a steady drip, drip, drip of issues through all stages of the project lifecycle, resulting in many months of wasted man effort to resolve and lost productivity; leading to missed milestones, project delays and the inevitable cost blow out.
Since manual builds are so time consuming, stressful, and error prone, the natural tendency in a project is to minimize the number of releases into each staging environment, and delay these until late in the project when the code in theory will be more stable.
Software components implemented in isolation are full of assumptions about the other components with which it will be integrated. Leaving integration towards the end is a high risk strategy, since issues with core architecture or design patterns, for example, may not be exposed until a project is almost completed.
This is especially the case for Oracle SOA and BPM projects, which involve integrating multiple systems together; it is a common mistake for all parties to agree on the interfaces between the systems and then go off and code independently (often for months), with a false sense of security that this is sufficient to avoid the worst issues when it comes to integrate these pieces together.
System integration and testing is then carried out towards the end of the project, just prior to going into User Acceptance Testing (UAT). Correcting invalid assumptions discovered at this stage in the lifecycle can result in significant time delays, be very costly and may even require significant areas of the code base to be re-written.
Test Teams Idle
One of the biggest wastes in software development is time spent waiting for things to happen. An area where this happens all too regularly is testing.
As previously mentioned, System Integration Testing (SIT) is often pushed back until late in the project, with developers cutting code up until the day before SIT is due to begin. At the eleventh hour, the build is run and the code deployed into the SIT environment, ready for testing to begin.
Unfortunately, for reasons already highlighted, the first delivery into SIT rarely goes smoothly, often requiring weeks or even months of elapsed effort by the development team to get the application to a state where testing can be performed. During this time, the test team is forced to stand by idle.
Once the first release into SIT has been successfully completed, it is not the end of the issue. Since manual builds and deployments are error prone, it means that process of deploying each subsequent release so that it is ready and fit for testing can be arduous. The deployed code will often fail basic “smoke” tests and require extensive troubleshooting and fixing before it’s ready to be tested, again with the test team left helpless on the sidelines.
Apart from wasting significant amounts of the test team’s time, the time spent troubleshooting the release is wasting developer time that should be spent on writing the code that delivers business value.
Defects Discovered Late in Delivery
Test teams are caught between a rock and a hard place; with each test cycle starting late for reasons outside of their control, yet the milestones for completing each round of testing remain fixed due to project pressures.
Squeezing the testing into a reduced timeframe, means the overall coverage and quality of testing is compromised, resulting in more defects going undetected in each round of testing.
The net effect is that defects are discovered later in the development cycle, or worse, make it into production. It is well known that the longer these defects remain undiscovered, the more effort it takes to troubleshoot and fix, resulting in significant project delays.
The business is frustrated when “development complete” code can’t be released, or unreliable code not fit for purpose is pushed into production – leading to the inevitable fallout and fire-fighting.
Continuous Delivery for Oracle BPM and SOA
The goal of continuous delivery is to help software development teams drive waste out of their process by simultaneously automating the process of software delivery and reducing the batch size of their work. This allows organizations to rapidly, reliably, and repeatedly deliver software enhancements faster, with less risk and less cost.
Applying Continuous Delivery in the development of Oracle Middleware projects can deliver significant reductions in development time and costs.
BRISBANE, Queensland (April 20, 2015)—Rubicon Red, an Oracle Platinum partner, announced today it has formed a strategic partnership with AVIO Consulting, an Oracle Gold Partner based in North American focused on Oracle Fusion Middleware. The partnership will widen availability of Rubicon Red’s MyST, the industry-leading provisioning and deployment automation tool for Oracle Fusion Middleware, in the United States.
"Clients repeatedly tell us the most important element of AVIO Consulting’s value proposition is that AVIO Consulting significantly lowers project risk and complexity based on our wealth of experience with Oracle FMW,” Gary Buffington, executive vice president of sales, said. “With the addition of MyST to our delivery capabilities, we can further reduce project risk and accelerate the overall project lifecycle. This allows our clients to capitalize on their investment in Oracle FMW faster and decrease the project risk more than previously expected."
Manually provisioning Oracle Middleware environments, plus deployment of code is resource intensive and error-prone. Deployment errors result in many wasted months of effort, causing project delays, plus significantly increases the risk of major production issues, with associated financial and brand damage.
MyST delivers automated platform provisioning and continuous delivery for Oracle Middleware, on-premise and on-cloud. Enabling users to deliver a consistent and reliable platform in minutes, NOT weeks or months. MyST is unique, being the only solution to combine concepts of “computer aided design” and “programmable Infrastructure” to automate the end-to-end process of designing and provisioning Oracle Middleware. With MyST, users model the required middleware infrastructure; which at the push of a button is provisioned by MyST. All with Zero Scripting!
As a result of the partnership, AVIO Consulting clients will now have access to MyST as well as the resources to assist with usage and knowledge transfer to the client team. With an average one-year ROI between 200 - 300 percent, AVIO Consulting clients can expect to see an immediate return on investment resulting from significantly reduced project complexity and risk. In addition, AVIO Consulting clients benefit from faster and more frequent provisioning capabilities.
“DevOps and Cloud are gaining mainstream adoption as the preferred delivery and operating models for modern applications,” Matt Wright, Chief Technology Officer, Rubicon Red, said. “The partnership with AVIO Consulting, a recognized thought leader in the delivery of Oracle Middleware solutions in North America, will allow organizations to utilize MyST to be more responsive in delivering new Oracle Middleware solutions faster, cheaper and more frequently.”
About Rubicon Red Rubicon Red offers organizations a set of innovative and market leading cloud and consulting solutions for Oracle Fusion Middleware customers. An Oracle Platinum Partner and recognized global leader in Oracle Fusion Middleware, Rubicon Red delivers thought leadership, innovation and unrivaled expertise. Founded in 2009 by two former senior executives from Oracle product management, Rubicon Red is an Oracle Certified SOA and BPM Specialist, and has been awarded the Oracle Fusion Middleware Top Technical Champion APAC on multiple occasions.
About AVIO Consulting AVIO Consulting is an innovative technology professional services firm focused on enabling enterprise agility and business process transformation through the adoption of Oracle Fusion Middleware technologies such as Business Process Management, Service Oriented Architecture and WebCenter. By combining years of strategic thought leadership and business transformation experience, AVIO Consulting helps companies build and execute strategies to best leverage products provided through the Oracle Cloud. Visit www.avioconsulting.com for more information.
Lets face it, provisioning production ready Fusion Middleware environments is not a walk in the park. And really it’s no surprise, its Middleware! It’s right in the middle of your systems and users, packed with a myriad of settings for you to tailor to bring value to your organization.
The Oracle Enterprise Deployment Guides for Fusion Middleware products take you through a step-by-step approach for building so-called production environments. It’s got all the kind of details you’d expect to see… but it is a "guide" not a gospel.
In reality, the EDG is the foundation, it’s the concrete slabs. With the EDG by your side, you will be building on solid, supported and proven infrastructure; ready for the onslaught of changes!
"We’ve confirmed last year’s performance findings: high-performing
organizations are still deploying code 30 times more frequently, with
50 percent fewer failures than their lower-performing counterparts." - State of DevOps Report 2014
Tools like Puppet and Chef (among the many other players like Ansible, Salt etc.) solve a very real problem. System configuration is hard to manage especially at scale.
Before these tools hit the market, configuration in the enterprise would often drift from a desired state and there was no easy way to detect or remediate this leading to inconsistent and unreliable platforms.
Let’s take a deeper look at one of these tools... Puppet.
What is the secret?
Puppet provides a domain-specific language (DSL) that can be used to define desired state of systems. It is vastly different from shell scripting. It is a fully declarative language that is designed specifically for configuring operating systems. It allows administrators to test desired changes safely, roll them out on demand and enforce them so that unintended deviations are detected and rectified. With model-driven configuration management solutions like Puppet, system administrators need to focus only on what they want not how.
In this case, Puppet is being used to tune a throttle limit setting. This definition will ensure that the limit is always equal to 300 regardless of the initial state.
1. Initial State
2. Puppet Apply
3. End State
Setting doesn’t exist at all.
Add the setting
The file containing throttling limit is se to 300. it is owned by oracle:oinstall with 644 permissions
Setting is different
Update the setting
File permissions are wrong on the file
Fix the file permissions and update file contents if required
The file is not owned by the correct user
Fix the file owner and update file contents if required
The settings has already been updated
The ability to deliver the same result regardless of the initial state is known as idempotency. If you apply a configuration and it makes the change once, on re-run, it will simply ensure the change is still there (rather than fail on create because it is already there!). With tools like Puppet this enforcement or drift correction runs on a schedule. If you were using shell scripts to make changes, you would still need to manually code the idempotency in. With Puppet (and crew - Chef, Ansible etc), good automation principles are built into the language so the desired state is visible and works consistently allowing you to focus on innovation around your core business.
Operating System Configuration vs Fusion Middleware Configuration
Tools like Puppet and Chef, have extremely powerful out-of-the-box types such as file, package, user, group and exec. They apply operating system configuration well and it comes as no surprise these tools are being rapidly extended by the community to support complex applications such as the Fusion Middleware product families.
But how does it all work?
The out-of-the-box Oracle supported automation tools are mature but pre-date the new wave of Configuration Management toolsets to the enterprise. Oracle Fusion Middleware automation is all about WLST, silent installation and CLI execution. But in their raw form:
WLST is not natively declarative or idempotent
Neither is Silent installation, OPatch, BSU and RCU
What is concerning is the trend around wrapping shell or WLST scripts in Puppet with the exec type with no intention to support idempotency and good automation principles. As organizations scale their platform with new settings, they require an administrator to map Puppet resources to WLST code. They are building idempotency in through a number of exec calls and processing the CLI outputs which is not a small effort. This is time consuming and requires specific coding knowledge well beyond the concepts of Puppet and Chef.
A declarative model for Fusion Middleware
In the next post we will look at some real world approaches for Model-Driven provisioning of Fusion Middleware that are used by SOA, OSB, BPM, WebCenter, IDM & Siebel customers world-wide to drive consistency, repeatability and reliability.
Oracle has announced today the release of Oracle SOA Suite 12c which marks a major step forward in supporting "industrial" SOA, and offer the industry’s most highly integrated middleware platform. With the rapid adoption of Cloud, Mobile and Internet of Things, the need for a robust, proven and standards based SOA platform has become central to an organisations ability to deliver on these key initiatives.
Matt Wright (Chief Technology Officer, Rubicon Red) was quoted as saying “Rubicon Red has been working with the SOA Suite 12c as part of the beta program, since early 2012. We are excited that Oracle customers are now able to take advantage of its many enhancements. Today, we are helping many organisations with their Journey to Cloud; the SOA Suite 12c, in unison with Rubicon Red's SOA / BPM Reference Architecture and tooling such as MyST (the leading continuous delivery automation tool for Oracle Fusion Middleware and Applications) provides business with a strategic advantage in their ability to be more responsive in delivering new solutions faster, cheaper and more often".
For more details on the advantages of SOA 12c, watch Matt Wright, describe many of the new features in Oracle SOA Suite 12c including mobile integration enhancements, unified development interface, cloud adapters, and more.
The rapid growth of cloud-based applications in the enterprise, combined with organizations' desire to integrate applications with mobile technologies, is dramatically increasing application integration complexity. To meet this challenge, Oracle today introduced Oracle SOA Suite 12c, the latest version of the industry's most complete and unified application integration and SOA solution. With simplified cloud, mobile, on-premises, and Internet of Things (IoT) integration capabilities, all within a single platform, Oracle SOA Suite 12c helps organizations speed time to integration, improve productivity, and lower TCO.
Click here to download the datasheet on what's new in SOA 12c.