Digital Cloud Platform for Restaurants

 My latest blog post for Capgemini is hosted at https://www.capgemini.com/us-en/2022/04/digital-cloud-platform-for-restaurants/

Reimagining Digital Transformation

 The restaurant industry is experiencing an unprecedented transformational change. Business disruptions from the global health crisis prompted the restaurant industry to restructure and diversify its operating model and digital portfolio in response to the shift of market trends and customer preferences.

Elevated expectations for cleanliness, health, and safety are accelerating the adoption of contactless technologies, curbside pickup options, and mobile payments to minimize human interaction. Gartner predicts most organizations will leverage contactless technologies for up to 80% of their ordering and replenishment activities by 2024.

Restaurant businesses must prepare to meet the operational requirements of the new normal and drive supply chain efficiency. Furthermore, restaurants should thrive to maintain brand loyalty by providing a seamless and differentiated omnichannel experience through enhanced digital capabilities.

In this post, we will show you how Capgemini’s Digital Cloud Platform (DCP) for Restaurants empowers the industry to reimagine digital transformation by delivering compelling customer interaction and streamlined operations while reducing costs and improving efficiency.

The full version of this article is published at https://aws.amazon.com/blogs/apn/reimagining-digital-transformation-with-capgemini-digital-cloud-platform-for-restaurants-on-aws/ 

Getting Application Modernization Right

 What is App Modernization?

You frequently hear the term - and this can cover and mean a wide set of things.

If you are hampered by your legacy IT systems, you will be keen to take up an application modernization. This is an overall transformation towards a highly scalable and always-on IT ecosystem that changes the traditional project driven mindset of longer release cycles. You want to get away from siloed functions and thinking of quality and operations as an afterthought, to a mindset where you are delivering and operating applications frequently, with much smaller release cycles, improved quality and automations. 

And delivering real business value - not just falling into a trap of measuring how many Story Points were delivered in each sprint. I've frequently seen Story Points as a false measure of business value 

App modernization should provides benefits to an enterprise that accelerate their journey towards a truly digital business - for example - enabling them to launch new and innovative products and focus on their core business instead of spending costs and time in resolving IT issues. 

Jigsaw Puzzle Timelapse Videos

My son and I assembled a 1000 piece jigsaw puzzle of the Cinque Terre view and recorded a timelapse video on the experience. 3 hours of recordings compressed into a 90 second video.

The video is hosted at https://www.youtube.com/watch?v=M2zqgsNXYSE 

Here is another 500 piece jigsaw timelapse of Neuschwanstein Castle

and a 500 piece video of a Paris cafe scene and another one which is a mystery 1000 piece puzzle of Alfred Hitchcock clues 

 There are links to some jigsaw puzzles down below. Each one is a 1000 piece puzzle

Enabling the connected vehicle

 The car of the future is connected, autonomous, shared, electric – and it’s already here. For example, by 2030, more than 95 percent of passenger miles will be served by autonomous cars. With sensors now built into every imaginable aspect of a vehicle, from fully voice-operated features and driver attention monitoring to biometric security for reducing theft, the possibilities for the customer experience are endless. Car manufacturers have started thinking beyond traditional car features like design and engine type to consider cutting-edge digital capabilities like personalized subscription services where user can opt in or out of a range of on-demand features from a centralized marketplace.

Because of this, customers have changed the way they purchase cars – it’s not just about aesthetics or performance anymore. There is a shift in customer preferences to include features like personalized digital entertainment and data-powered productivity. Connected cars of the future will also offer facial recognition systems that change in-car settings for the driver, in-car gesture control and voice recognition for advanced security, and in-car shopping with geo-based prompts.

Capgemini’s research indicates that the automotive industry is a leading adopter of smart factories and use of digital technologies such as IoT connectivity, intelligent automation, and cloud-based data analysis and management. However, to take advantage and truly commercialize on the possibilities of the connected vehicle, automotive leaders need to ensure they have a strong technological foundation and that they are:

• Adopting next-gen capabilities that will drive innovation. This includes 5G, cloud, and AI. In fact, up to 15 percent of all new vehicles sold in 2030 could be fully autonomous using next-gen capabilities.
• Conforming to safety and security demands. Given the sensors and the data-driven nature of connected vehicles, they may be more prone to hacking. But turning control completely over to software could lead to new hacking vulnerabilities and other liability issues that companies cannot ignore. To overcome this, automotive companies have to allow drivers to intervene in emergencies.
• Choosing the right operating systems, hypervisor options, embedded software design, and hardware compatibility. These parameters are critical factors to consider given the increasing share of electrified vehicles as a percentage of new vehicle sales. For electrified vehicles, it’s important to have the right OS and embedded software and software.
• Enabling rapid prototyping, development, and testing/verification. There’s no denying that the future of the automotive industryis tied closely to additive manufacturing. Continued innovations in the 3D printing industry – including new materials, printers, and techniques – will continue to change the way companies design and create. To remain competitive, or simply stay relevant, organizations need to adopt smarter and faster ways to prototype and develop.
• Enhancing the capabilities behind design and production. A connected vehicle requires multiple end-to-end capabilities. The industry is in a critical period of disruption, and those who build in the software capabilities in the same way they think about hardware will be able to win mindshare and market share over the long term.
• Think beyond the vehicle. For connected cars, the ecosystem is not just within the vehicle. Because of this, automotive manufacturers need to work with fleet suppliers and service providers to deliver sustainable, connected value across the ecosystem. For example, automobile manufacturers need to work with city planners for better sustainability options such as placement of electric vehicle charging stations based on data.

The automotive industry is at an inflection point that is very similar to that of the telecom space in 2010 with the emergence of Apple. Software architecture will drive the future of the sector, and automotive CIOs need to take advantage of the opportunity by prioritizing the capabilities and differentiating features of their vehicles and connecting with service providers to deliver next-gen customized experiences.

This post was originally published by the author at https://www.capgemini.com/us-en/2021/04/enabling-the-connected-vehicle/ 

The value of a platform approach in a cloud-native environment

 A  potential challenge that IT teams face when in a cloud-native environment is working within a highly distributed ecosystem with multiple moving parts, such as microservices and containers. If design patterns are not followed or implemented correctly, achieving maximum value can be a challenge. Because of this, we recommend a platform approach for any organization looking to embrace cloud-native development.

How is a platform valuable?

A platform-centric approach provides a framework with best practices and proven patterns that have worked not just within a single organization but within others as well. A platform is a base set of capabilities and features that provide the foundation to optimize and innovate, in this case within a cloud-native environment. It can encompass technology elements as well as processes. For example, we worked with a global wireless carrier to establish two platforms: one was based on microservices with a standard technology set and the other a DevOps implementation containing standard tools, processes, and technologies. A platform can integrate with partners, suppliers, and consumers and drive your business capabilities.

From a modernization standpoint, a platform provides the infrastructure for transforming from haphazard communication between legacy systems to well-defined reusable services. This standardization allows a company to react to change faster. A platform is horizontal and sits outside any specific line of business, which facilitates standardization that simplifies the process of making technical changes while promoting efficiency and scalability. For example, Capgemini worked with an organization to build a NoSQL datastore when the traditional online database became a bottleneck. The underlying platform capabilities, such as the event bus, were essential for the technical team to make a decision on a solution, pilot it quickly, and launch to production without an impact on operations.

What should a platform consist of?

A platform is essentially a pre-defined set of APIs and services that enable and support applications, data, and business capabilities for the enterprise. It can include operational, orchestration, data, and network components as well as lead up to AI algorithms, DevOps tools, and security services. These pre-defined APIs and services can also be specific to your business and technology, as in the case of core business functionalities that are exposed by legacy wrappers for consumption by the business. A platform also includes a mechanism for standardizing across lines of business, allowing specific teams to request features via self-service provisioning. It also includes a sandbox for trying out new capabilities to be added.

Should you build or buy your platform?

A platform exists to facilitate the rebuilding of the portfolio and should improve processes. When thinking about how to construct a platform, you can opt to build these capabilities in-house or leverage third-party services like Kubernetes or PaaS features from a cloud provider.

Technical leaders should look at platform roadmaps to progressively migrate business operations from existing systems to platform capabilities. For example, re-architecting a legacy monolith as PaaS services requires the use of existing re-usable and production-proven capabilities that maximize efficiency and reusability. This is, in essence, a shift to a platform approach, facilitated by the process of application modernization. In the platform approach, all modernized capabilities are built to be reused internally and externally, enabling the move to API monetization.

It’s important to remember that the transformation to a platform-centric approach will not happen overnight, and we don’t recommend going for a big-bang migration approach to a new platform. Rather, we recommend first conducting a pilot project with a group that embraces change, and then building from there.

 For more information, please check out The app-modernization manual: The definitive guide to building intelligent apps from Capgemini, or reach out. This was originally published by the author on https://www.capgemini.com/us-en/2021/01/the-value-of-a-platform-approach 

API Security Testing Checklist

 API should be checked for the following from a Security perspective:

1. Denial of Service Attack https://owasp.org/www-community/attacks/Denial_of_Service

2. OWASP A6- Security Misconfiguration https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration.html 

2. IP Access Control https://owasp-top-10-proactive-controls-2018.readthedocs.io/en/latest/c7-enforce-access-controls.html

3. MITRE CWE 250 Unnecessary Privileges - Basic Authentication

4. Ensure no direct access to database.

5. Access token authentication - e.g. OAuth* 2 with JWT for user authentication and authorization. 

5. API Key Generation & Validation - API providers should expose secure methods to provide authorization code or access tokens on demand.

Making Digital Business a Reality

 

I presented a successful case study on Digital Business at The Open Group Summit April 2020.

The video is at https://www.youtube.com/watch?v=G0QcC2qvnG0 

Five tips to dramatically accelerate app development

An article I authored is published here

https://www.capgemini.com/2020/04/five-tips-to-dramatically-accelerate-app-development/ 

Practical Learnings on Microservices

 An article I authored for my corporate blog on this topic is here

https://www.capgemini.com/2019/06/practical-learnings-on-microservices/ 

List of bands I tune into

Checklist of my favourite bands for me to keep tabs on their latest offerings

A Perfect Circle discography

Bon Iver

Cary Brothers

Coldplay

Daughter

Dave Matthews Band

Favourite songs: Dont Drink The Water, Crash

Last Album: Away From the World

Duncan Sheik

Evanescence

Fleet Foxes

Frou Frou

Imagine Dragons

Imogen Heap discography

Favourite Songs: Monster, Radioactive

Jose Gonzalez

Joshua Radin

KT Tunstall

Linkin Park

Last Album: Living Things

Mumford and Sons

Pearl Jam discography

Red Hot Chilli Peppers

Sarah McLachlan discography

The Corrs

The National
Last Album: I am Easy to Find
Favourite Songs: Ada, This is the Last Time, Tunnel Vision

The Weepies

Tori Amos

U2

Container Volume Options and Features

Background

Containers need a mechanism to store data, without which it will not be useful. Virtual Machines have the quality that once started, any modifications are saved as a new VM. Containers on the other hand are transient and are not designed to store any state that the application generates

Types of Container Storage needs

Image Storage:

The first is image storage. This can be provided with existing shared storage and has requirements much like platforms already built for distributing and protecting virtual machine (VM) images in server virtualization.

·       The benefit is container images are much smaller than golden VM images because they don't duplicate operating system code.

·       Also, running container images are immutable by design, so they can be stored and shared efficiently. There is a consequence, though, as the container image cannot store dynamic application data.

The second required data store is for container management

Again, you can readily provide this with existing storage. Whether you use Docker, Kubernetes, Tectonic, Rancher or another flavor of container management, it will need management storage for things like configuration data and logging.

Third storage require for container application storage:

It's the third type of storage, container application storage, that provides the most difficult challenge. When only supporting true microservice-style programming, container code can write directly over image directories and files

But containers use a type of layered file system that corrals all newly written data into a temporary, virtual layer. The base container image isn't modified. Once a container goes away–and containers are designed to be short-lived compared with VMs–all its temporary storage disappears with it.

Container Storage Options

·       Docker also has a concept of volumes, though it is somewhat looser and less managed. In Docker, a volume is simply a directory on disk or in another container. Lifetimes are not managed and until very recently there were only local-disk-backed volumes. Docker now provides volume drivers, but the functionality is very limited for now (e.g. as of Docker 1.7 only one volume driver is allowed per container and there is no way to pass parameters to volumes).

·       A Kubernetes volume, on the other hand, has an explicit lifetime - the same as the pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data is preserved across Container restarts. Of course, when a Pod ceases to exist, the volume will cease to exist, too. Perhaps more importantly than this, Kubernetes supports many types of volumes, and a Pod can use any number of them simultaneously.

Container Volume Problems

·       On-disk files in a container are ephemeral, which presents some problems for non-trivial applications when running in containers. First, when a container crashes, kubelet will restart it, but the files will be lost - the container starts with a clean state.

·       Second, when running containers together in a Pod it is often necessary to share files between those containers.

Solution: The Kubernetes Volume abstraction solves both problems.

·       A Kubernetes volume, has an explicit lifetime - the same as the pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data is preserved across Container restarts.

·       Of course, when a Pod ceases to exist, the volume will cease to exist, too. Perhaps more importantly than this, Kubernetes supports many types of volumes, and a Pod can use any number of them simultaneously. Kubernetes contains a property, volumeMounts. subPath, to specify a subpath inside the referenced volume.

Practical Learnings on Microservices

In a recent project, we delivered over 60 Microservices deployed on multiple Tomcat servers each in Production.

Below are some notes on real-life learnings.

Designing the Microservices:

•Business focus
•Small services with CRUD operations on single business function or domain 

•Design
•Use Lightweight REST based communication (client-to-service and service-to-service)
        •Keep Loosely Coupled
       •Ensure Services are Stateless
•Appropriate design patterns such as Aggregator, Proxy & Branch Patterns are commonly used
•In unavoidable cases - there will be Distributed Transactions and need to design for them

•Resilience
•Must design for Failure – e.g. Delays, Errors or Unavailability of another service or 3rd party system.
•Provide default functionality in case of failures from a service
•Rely on Input Validation - (client-to-service and service-to-service)

•Observability
•Centralized Logging and Monitoring is a must across distributed microservices

•Log events for timeouts and shut downs

•Logging to include the level, hostname (instance name), message

•Log events can be used for capacity planning and scaling e.g. which services need higher instances

•Business data related metrics such as no. of Bookings, Time taken to fill out the form 

•Log events which can be used for capacity planning and scaling

•Automation
•Use Testing tools for integration of services
•Quick feedback on check-ins and failures in the CI/CD pipeline

Benefits:

§Independent Development teams

•Business domain-driven design

•Responsive to business changes

§Independent Deployments

•Minimal impact and regression testing for small fixes

•Able to quickly take down and redeploy one service without impact to the overall system or other functional services.

§Independent Scalability

•Slots well into on-demand hosting and cloud services for scalability 

§Reusability for other Enterprise projects

Constraints:

§Higher Complexity for developers initially

§Deal with error handling, timeouts, retry mechanisms

§Service versioning can get confusing and needs to be managed.

§Managing Distributed Transactions requires Design rework.

§Requires increased number of VMs to support environments adding to infrastructure costs
§Need clear deployment strategy at the start to identify which services will be deployed on which VMs

§Increased overhead for Configuration management and Rundeck/UDeploy deployments during project life cycle and in production as a result of 60+ separate code builds and deployments

§Across environments, there are 240+ Tomcat Servers in Production and 480+  Servers in lower environments