Tag: Cloud

Co-creation 101

~ Danny Kwok ~ Leave a comment

Have you tried Co-creation process with your consumer or contractor? It is a form of collaborative method where two or more parties work to contribute to the product development. Open source software is a good example of this approach. With Cloud platform, you can also adopt this method to actively digital transform and create your knowledge capabilities in-house.

Why Co-creation?

Self-service and satisfaction are the major push for co-creation. The need of self-service allows users to create products with closer fit to their expectations and requirements. This brings increase satisfaction and commitment to the success of the product. Co-creation also allows greater participation throughout the product lifecycle. It is best aligned with agile process to adapt to changes.

Setting Ground Rules

The approach to implement co-creation depends on your needs. It is important to set ground rules if you wanted to engage your users or contractors for co-creation process. Some of these ground rules involves the level of control or access the co-creation can cover. Other forms of collaboration involves the communication and risk entails by the participants. The most important portion is to ensure information transparency among the collaborators.

Co-creation approach works well with Agile for Cloud. It is the best middle ground approach between outsourcing and insourcing model. You can gain internal capabilities and ensure better satisfaction for your users with self-service technologies. However, do take note to set ground rules before you embark on your first co-creation project.

Cloud EA

~ Danny Kwok ~ Leave a comment

EA (Enterprise Architecture) will be seeing a revival with Cloud. Many knew TOGAF as the de facto EA from our pre Cloud days. It was an uphill task to implement EA in the past. This was because infrastructures were physically difficult to change once implemented. Perhaps it is time that we relook EA from a Cloud perspective ie. Cloud EA.

Cloud EA Vision

Cloud EA will be emerging as a standard template as the competitive cloud market aim to differentiate against each other. For now, let us have a quick look at what the vision of Cloud EA will be. Some characteristic of Cloud EA are:

  • Ubiquitous deployment of applications based on cost and business needs.
  • Automatic selection of Cloud EA like fault tolerance or high availability.
  • Standardised default security setup for Cloud EA
  • Business driven artefacts and information.
Current State

In reality, Cloud EA may take a few more years to mature. The alignment of business and technology in Cloud remains holistic in nature. This means Cloud EA existed as initiative or vision like its predecessor EA. However, it is optimistic for Cloud EA. Cloud providers will introduce Cloud EA models that can be readily deployed.

Cloud EA will be the next generation model for cloud providers. There will be a demand for customers to have control over their EA to align to market needs. Thus, this can easily translate to Cloud implementation as EA level.

OTM Upgrade Journey

~ Danny Kwok ~ Leave a comment

OTM (Oracle Transportation Management) upgrades are a challenge on its own. It is expected that majority of on premise OTM should move to Cloud by 202x. This push factor is spurred by the end of support of on premise enhancements. However, the switch to Cloud is met with resistance and lack of clarity on how Cloud can cater to customisation of OTM aka CEMLI. Finally, it seems that an extension is given with the release of OTM version 6.5.x. The question is what’s next? Should you continue with on premise?

Message from OTM 6.5.x

The release of OTM 6.5.x give a sign of relief for organisations who are still using on premise OTM. The push to Cloud remains and the vision to innovate OTM Cloud is still the key objective. It is likely the feature gap between 6.5.x and OTM Cloud widen to the extent that it is no longer advantageous to remain with on premise version.

Flipping the Switch to Cloud

Migration to Cloud will always be a painful process. It is a matter of time before you need to flip that switch to Cloud. There are many case studies on migration to Cloud for OTM with lesser customisation. However, it is unclear on how heavily customised OTM shall proceed with the switch. What are the type of approach available? How can we make the switch with minimum disruption to operations?

OTM upgrade remains a long marathon for on premise. Time has shown that OTM Cloud will be the de facto platform. It is estimated that on premise upgrade journey may end in 5 years time. Who knows? Maybe, there will be OTM 6.6.x.

Upgrade or Migrate to Cloud

~ Danny Kwok ~ Leave a comment

With strategic change of many software companies to cloud, organisations have two options for their aging applications. One, you have to upgrade to the latest version to extend their support life. Two, you migrate your application to cloud version. What will be your rational for these options?

Upgrading Rationale

Cloud based products differs from their counterparts because of the ease of customisation. The extent of customisation and your comfort level to risk will determine how much you will opt for upgrading options. However, the major risk continues to exist due to the end of support for your application. Upgrading options only help to extend time needed for your preparation to cloud.

Cloud Migration

Cloud migration should be the default choose because the end of support is real. Regardless of the option taken, the end game is cloud migration. However, cloud migration involves entire redesign of your architecture. There are also refactoring done to existing codes. The key difference with upgrading rationale is the higher risk. The risk includes the architectural changes and code changes that will impact your customised product.

The option to upgrade or migrate to cloud differs in the duration or risk management. The end point will remain as migration to cloud. Upgrading are able to provide you extra time to lower your risk to cloud.

Cloud Gateway 101

~ Danny Kwok ~ Leave a comment

Cloud gateway is going to be a standard cloud architecture design for secure applications. There are many flavors of gateways but we will seek to understand some of the basic ones and why we need it for a secure and resilient architecture.

What are Gateways?

Cloud gateways are services that act as a bridge, control or connection between two or more distinct objects like applications, on premise and cloud. Gateway also acts as gatekeeper, throttle or insulation against healthy or malicious network traffic. In summary, gateway is another layer of protection to prevent your backend architecture from a complete meltdown if there are any vicious attacks in the Internet.

Gateway Type

These are some common gateways that you will likely adopt for your cloud architecture.

  • API gateway isolate, manage and controls the communication to your backend services and API calls like REST.
  • NAT gateway control and translates network traffic between different networks.
  • Storage gateway manage the storage from cloud to on premise storage.

Gateway is one of key components for designing of secure and resilient cloud architecture. Many cloud providers allows you to template and setup these gateways with default settings with ease. Thus, it is recommended that you must implement these gateways properly.

APEX REST Data Synchronisation to Local Table

~ Danny Kwok ~ Leave a comment

Oracle APEX has an interesting feature to let you synchronise your external REST API to local database. This helps in caching and logic processing in your APEX. You can easily enable this feature without coding.

A Plus for APEX

The REST data synchronisation feature is a plus point for developers to use APEX. This is because it is common to consume or send processed data via REST API. Data replication for faster read access is also a useful feature. After learning about this feature, I find that it is very simple to enable data synchronisation.

Maintenance

It is not difficult to maintain this feature when the data can be cached to local database. You can also schedule refresh at different time interval. Majority of the configuration can be maintained via APEX page. It is important to take note of the following points for future maintenance.

  • Response JSON format
  • REST endpoints
  • Primary key
  • Field type
  • Parameters

If you are looking for an application for consuming multiple REST data sources. You can trial APEX data synchronisation. This feature is really useful to setup without additional coding.

Plan for Security Review

~ Danny Kwok ~ 1 Comment

Security review is a common process for new application. It can be time consuming and when security and application cannot align focus on a common ground. These are some tips where application team can preempt and prepare for security review.

Design for Security

Often, application design focus on security requirements prior to go live. This can be detrimental when security team do not approved the architectural design because of security concerns. It is important to consider security design from day 1. Cloud security is one key area that is standard for all cloud deployments. Thus, the rule of thumb is to design security before you start your application development.

Iterate Security Review

Security review is an iterative process. Alignment with security expectations is important to secure the features. However, there are times where timeliness and cost outweighs the security request. You should iterate the security requirements and align on a common understanding. One such method is limit the exposure of your data in public subnet. Do note that it is not possible to clear security review in one setting. Thus, it is realistic to plan for security review process in your application development.

Security review is a common process for cloud development. This is because the notion of cloud is not within your own secured space. Therefore, you must include security design from the start of your project and plan for security review process. Getting the sign off from security team will lend confidence in your application.

Upgrading 123

~ Danny Kwok ~ Leave a comment

Upgrading remains a major project for many on premise and legacy applications. It is really quite a pain and this is one reason why I favor Cloud platforms. In the meantime, I hope that I can do upgrading for the last time. These are some tips that the future may not be using for upgrading exercise.

Get the Right Team

The upgrading team is usually a separate team from the support team. This caused a disconnect with miscommunication and the need of knowledge transfer process. There are also instances where upgrading team miss out key components. After all, we suppose the upgrading team to be well versed in the new application. However, the team must involve a right mix of support team to understand the application landscape.

Agile and Systematic

Unfortunately, many upgrading projects follow waterfall model. I favor Agile and systematic approach. In all upgrading project, you need to be systematic in the changes you are doing. You must also be agile to adapt to new options of the upgraded components become a showstopper. Therefore, waterfall model is painfully slower and subjected to delta changes.

As long you are having legacy or on premise application, you will still be having upgrading nightmare. A move to Cloud will cut these costs and time as upgrades are done seamlessly backend. Hopefully, we will not suffer more upgrades in future.

ORDS REST POST Insert

~ Danny Kwok ~ 3 Comments

ORDS (Oracle REST Data Services) REST is using POST for its INSERT SQL commands. You can setup ORDS POST insert quickly with these default settings.

The Setup

POST insert has a different configuration from GET. These are some of the settings to take note.

  • The source type must be PL/SQL.
  • Remember to set mime types to application/json.
  • It is important that you setup a PK (primary key) for the table to be inserted.

Reference source: ORDS POST Insert

Common Errors during Testing

You can use tools like Postman to do your API testing. These are the errors that will cause the API to fail.

  • Content-Type must be set to application/json.
  • Body format must be set to JSON.
  • Charset must be set to UTF-8.
  • Custom parameters name to exclude dash.
  • Missing PK in table.
  • Check your typos in the JSON payload.
  • Check your typos in PL/SQL.

ORDS POST insert will be easy to setup. However, you need to take note of the common errors. Hope this will help you to save several man hours in finding the issue.

ODA Chatbot using Bucket Storage in Cloud

~ Danny Kwok ~ Leave a comment

You can easily setup static website with storage bucket in Cloud. Do you know that you can extend this setup for your ODA (Oracle Digital Assistant) Chatbot? This is provided as a JavaScript library for the Chatbot web channel.

The Setup

The setup is much easier than I had thought. This is a standard setup for ODA Chatbot web channel.

  1. Create folder for JavaScript and css in the object storage bucket.
  2. Create index.html or any main page for linking to ODA Chatbot.
  3. Create authenticated URL with access to the all objects within the bucket.
  4. Test your URL to start the Chatbot.

The setup of ODA Chatbot using web channel is simpler using the object storage architecture. You do not need to create new server instance or worry about the server capacity. This is because object storage comes with having high availability and huge storage.