Defining the Cloud
The term cloud computing is a general-purpose word that describes provision and consumption of remote computing resources. If the question is posed: "How do we implement/migrate a software package to the cloud?" the necessary first response should be a clarification discussion to understand what the asker means by the cloud. There are common models applied to cloud computing which can help constrain the ask above, specifically the service model and deployment model. These are important to understand, because these models constrain the scope under which a software package or configuration must operate. There are multiple characteristics that are common to cloud computing platforms, but the most important are:
The service model includes some common terms that you might already understand: IaaS, PaaS, SaaS, and others. With respect to Documaker, currently only the IaaS or PaaS models are applicable, so the others will be ignored.
In the Infrastructure as a Service (IaaS) model a cloud services provider makes available a computing infrastructure onto which you can install your desired operating system, applications, tools, and data. In this model, you, as a customer, are responsible for the operating system, software and data, while the cloud provider is responsible for the infrastructure such as network, servers/virtual machines, storage, load balancers. Simply put, IaaS is like a sandbox in which you can build your castle, but you have to supply the molds and tools and the cloud services vendor provides the box and sand.
In the Platform as a Service (PaaS) model the cloud services provider makes available a set of computing services, such as a database, execution runtime, tooling, and other components onto which install your application and data. In this model, the customer is responsible for custom applications and data which may (or may not) use the cloud vendor's provided applications and services that are running on vendor's infrastructure. Continuing with the sandbox analogy, under PaaS you can build a castle but you must use the vendor's box, sand, molds, and tools.
To be complete we can briefly discuss SaaS, which is the model in which the vendor provides and manages the infrastructure, services, and applications while you the customer provide the data. A real-world example is a service like Oracle's Financial Services Cloud Communication service. The SaaS sandbox doesn't allow users to build their own castle, but you can play in your own section of the vendor's prebuilt castle.
The choice of deployment model largely depends on requirement, risk, and cost. Documaker does not specifically require one model over another in terms of requirement, so long as the underlying hardware/software requirements are met in the service offering. Requirements become a primary factor in the deployment model when considering the solution and its integration points. For example, if your Documaker implementation contains integrations to upstream or downstream software components, these must be considered in the deployment model choice. There are three typical deployment models usually offered by cloud providers:
There are a number of vendors that provide cloud services, such as Oracle, Microsoft, Amazon, Google, IBM, and others. As one might expect, each vendor has differentiating characteristics that may make them more suitable for one use case or another.
For example, Oracle's cloud approach is based on its history of security and governance, which has resulted in a cloud services architecture that enables silos for application control and data. Amazon Web Services (AWS) has a huge marketplace with global reach that makes it easy for startups to quickly create new applications from the ecosystem of AWS tools. Microsoft's Azure system is embedded with Windows applications and tooling, making it a good choice for businesses looking to migrate existing Windows-based workloads.
When developing a business case for moving workloads to the cloud, service offerings are a first concern, however they are not the only concern. Cloud vendors have shared characteristics in their design and deployment that is exposed to the customer. Most vendors have similar objects, nomenclature, and processes that are used to perform common tasks such as deploying a virtual machine into an IaaS environment. Underneath those commonalities there are differences in network topologies, infrastructure maintenance procedures, redundancies offered, service level agreements offered, and more.
All of these items are reflected in the price that you, as the customer, will ultimately pay to consume those services. It is important to consider these elements when making a business case and plan to migrate workloads to the cloud. We might consider the hard costs of cloud migration e.g. your workload is X, and the cost of X is X*Y1 for Oracle, where the workload is considered in terms of compute cycle costs or data I/O costs. It is important to consider soft costs as well: how is elasticity/service levels guaranteed and what happens when service levels aren't met? How is governance enabled and what are the potential risks and business costs if there is a data leak or non-compliance with regulations? This list is simply to spur thought, and is not conclusive.
Documaker in the Cloud
Undoubtedly the most pointed question will be is Documaker version X supported on Vendor Y's cloud platform? and the answer still still not quite straightforward as we still have variables to consider. Any long time architect of Documaker services probably understands that Documaker is at its heart an extremely capable set of tools with some prefabricated use cases to support common business operations for generating communication. This has been the case for nearly two decades until the advent of Documaker Enterprise Edition, which sought to push the envelope of Documaker into a more modular approach with established use cases, while still supporting existing Documaker libraries.
To answer the question we need to understand the Documaker solution that is being migrated. Your solution could be some or all of these (or more):
In short, there is not a simple answer, however there are some general guidelines that can be followed. First and foremost is you should being with a catalog and understanding your current system. You should know:
With this information in hand you should be able to form a picture of what should be considered in a workload migration.
An overarching concern that should influence every facet of your cloud journey is the need to execute regression testing, both in the literal and figurative sense. Your private sandbox in your corporate data center that has never been exposed to the outside world may be moved to a public cloud, and your existing regression test suites may be nonexistent or may be lacking in scope to adequately test the wholesale movement of business processing onto a new platform. Consider the application boundaries presented by the solution and how those may be affected by migration to a cloud environment. Your corporate governance structures may lack the scope and depth necessary to encompass the wider security concerns presented by moving business applications onto a cloud infrastructure, and should be taken into account as well.
For example, if the entire business application suite is moving, the boundaries may be entirely non-existent. If only some of the business application components are moving to a cloud environment, there are now boundaries that did not exist previously. Those boundaries will need to be adequately tested in your regression test suite. Similarly, governance structures may not account for these boundaries since they do not exist currently. There may be some governance rules in place, but they may lack the scope necessary to address a cloud deployment, and so these must also be considered. A concrete example of a boundary is represented by Documaker Studio. This application runs on a user's workstation or in a virtualized workspace like XenDesktop or Citrix, and accesses the database for interacting with form resource libraries, typically in a development environment. The application may also be used to interact with other environments to facilitate migration of changes to downstream environments. If the Documaker solution is moved to a public cloud infrastructure, you will need to consider how to address the solution boundary presented by the separation of your corporate users and the application now running in the cloud infrastructure. Thankfully this is not a problem that is specific to Documaker, and is a common use case that is typically addressed by using virtual private networking between your corporate network and the cloud provider network.
Diving in the service models that you might consider, the simplest level is represented by a migration of a Documaker workload from an on-premise datacenter to an IaaS cloud offering. This migration presents the least risk and complexity, as long as the cloud vendor meets the requirements that you have outlined in your solution requirements catalog. The lift-and-shift into a like-for-like environment is not without risk so long as there is adequate regression test coverage and identification/mitigation of potential issues beforehand. A typical migration might involve a migration from Documaker on Oracle Enterprise Linux 7 machine in your corporate data center to an Oracle Enterprise Linux 7 virtual machine in the cloud infrastructure with similar characteristics. Not all vendors offer the same operating systems and versions, but Documaker is generally flexible in terms of OS, so you need to consider this scope in your regression testing to ensure it does not present any issues.
It is important to point out that on some platforms, Documaker does present some specific requirements that should be captured in your solution and requirements catalog. For example, on a Linux-based platform there are some prerequisite components that must exist, and must be at certain version levels e.g. libgcc and libgcc.i686 are required.
The next level of complexity is represented by the PaaS service model. Recall that PaaS provides a set of computing services, such as a database management services, middleware, and development tools. Under this model, more components are provided for you, and this represents additional risk since they may not be offered at the level required to match your solution and requirements catalog. There is also the possibility of mixing IaaS and PaaS in some implementations. For example, you may deploy Documaker to an IaaS platform, but take advantage of an RDBMS PaaS offering - you must keep in mind there may be some limitations in your ability to change some aspects of a PaaS offering. For example, you may not wish to use Azure DB with Documaker Enterprise Edition and support certain languages because your Azure DB may not be set up with the proper collation to support foreign languages. Additional risks may be present in other cloud-based services that have not been explicitly tested with Documaker.
Q1. Can I deploy Documaker to the Cloud?
A1. Documaker (both Enterprise and Standard) has been successfully deployed in Oracle Cloud Infrastructure (OCI), Amazon Web Services (AWS), and Microsoft Azure.
Q2. Who is running Documaker in Cloud environments?
A2. There are a number of large corporations who are currently migrating their Documaker workloads to the cloud. However, we cannot release this information publicly. You may consider joining the Documaker Client Advisory Board (CAB) whose membership includes many Documaker customers with whom you can discuss such matters.
Q3. Can I use my Documaker license in a Cloud environment?
A3. There is not a one-size-fits all answer here, but generally you should be able to do so. If you have a concern you should contact your Oracle license sales representative, or Oracle Support for additional information.
Q4. Which cloud vendor should I use?
A4. The choice ultimately depends on how well a provider's solution matches your solution and requirements catalog, so the answer depends on the scope and breadth of the catalog. Your catalog should also include soft requirements as discussed above. Finally, such a decision involves cost/benefit analysis, risk analysis, and return on investment. These elements are outside the scope of this paper, but as has been alluded to in the above, there are wider concerns than just putting your data and applications on someone else's computer - there are governance and security concerns as well. In any case, Documaker is an Oracle product, and Oracle platforms typically receive the most attention in terms of product development and support, so you can't go wrong with Oracle Cloud.
If you have additional questions, thoughts, or concerns, feel free to post a comment below, or head over to the Documaker community.