Category: Technologies
Posted by: bagheljas
Microsoft Azure Architect Technologies & Design
Category: General
Posted by: bagheljas
The Cloud Native Application Architecture is the leading mainstream application architecture to stay relevant for 2020 & beyond. The key business drivers for Cloud Native Application Architecture are:
  • Speed of Deployability of Everchanging Users Needs and Industry Innovation
  • Economical Application Experimentation and Operations & Maintenance
  • Ability to Utilize Best of Breed Technology, Platform and Framework and Adopt Next One Leading in Industry
The Cloud Native Application Architecture Pillars are identified in the diagram below to develop and deliver an Enterprise Could Native Application Architecture Strategy and Solution.
Cloud Native Application Architecture Pillars
  • Micro Services - Services based application design pattern that creates end to end loosely coupled services also known as micro services to build an application. Each micro service is expected to bind by the service contract of the function it delivers at agreed performance and availability. Micro Service Owner is empowered to pick the best of breed technology, platform and framework suited for delivery of the function. Each service maintains its own independent software release cycle and run time environment for end to end autonomy. The end to end Autonomy is the key to receive true benefits of the Micro Services and may require Enterprise Architecture changes not just implementing an application utilizing fine grain services.
  • Serverless & Containers First - Lightweight run time environment and/or compute resources are mission critical for successful Micro Services based Application Design and Delivery. It is cost prohibitive to live with traditional run time environments that can deliver micro services autonomy. One must think Serverless & Containers first or have business justification to pick compute deployment model otherwise as a leading practice. Enables portable deployments that are not tide to an operating system and server platform.
  • Everything as Code - In other words, plug-in automation everywhere just not for software release. Mutable deployments are critical for an efficient cloud native application architecture. Package everything as code in one package for infrastructure, application run time, application deployment, testing, user acceptance, security & compliance, and monitoring to deploy and scale application services at the cloud speed economically.
  • DevOps and Continuous Integration & Continuous Delivery (CI/CD) - DevOps is all about bringing end to end software release cycle under single leadership at the first line manager and automation to deliver the software to end users. This may require changes to Organization Structure and Enterprise Architecture. It is a leading practice to create CI/CD pipeline for each micro service of an application to provide Micro Services Autonomy. The first line manager now got the ownership and team with skills that can design, build, deliver and support the application service at the cloud speed.
  • Application Programming Interface (API) Economy - Expose organization's digital services and assets through API in a controlled way for ease of integration between partners and applications, minimize duplication and develop & deliver new capability at the cloud speed.
  • Artificial Intelligence for IT Operations (AIOps) - Use the team human resources to perform high value services then spending cycles for typical mundane task that could be automated to maintain and support your application operations. Send logs and events into a system that can analyze, learn and identify issues reactively, proactively and predictively, and has the ability to perform the resolution for the mundane repeatable tasks by augmenting intelligence to your team supporting application operations.
Category: General
Posted by: bagheljas
One needs to carefully plan and understand the Cloud Responsibility Model aka Shared Responsibility Model to ensure that there is no gap in the services needed to run the operations smoothly. The cloud deployments by default doesn't take over all the responsibilities and ownership necessary to run business digitally. The Cloud Responsibility Model below gives you an out of box responsibility framework for a typical deployment model types. It is a leading practice to start with out of box shared responsibility model but build a comprehensive Responsibility Assignment Matrix aka RACI with the Service Provider before going live in the new Cloud and/or Outsourcing Managed Services Model.
Cloud Responsibility Model
Category: General
Posted by: bagheljas
The Security Solution needs account the solutions for each layers described in the diagram. In specialized cases, one can assume risk but in most use cases, one should identify and implement solution for the common threats to complete the security solution. Defense in depth is all about having the security protection at multiple layers. The Security Model can serve as the point of reference when we are working on the Security Solution Design.
Security Layers Model
Category: General
Posted by: bagheljas
IP Address is also known as Internet Protocol Address. The Internet Protocol Address assignments are managed by the Internet Assigned Numbers Authority (IANA). IANA has divided the IP Addresses in two groups. First named as Public IP Address and second named as Private IP Address. The Public IP Address has to be unique in the whole world. Hence, Public IP Address is routable to internet. The Private IP Address is reserved to build private network controlled by the owner of the private network without coordination with IANA and the Private IP Address are not unique in the world. Hence, Private IP Address by default is not routable to internet. IANA has reserved the the following IP addresses to create Private Network by anyone:
  • Class A: 10.0.0.0 to 10.255.255.255
  • Class B: 172.16.0.0 to 172.31.255.255
  • Class C: 192.168.0.0 to 192.168.255.255

The table provides a quick guide for sizing Virtual Networks/SubNets. The Virtual Networks and SubNets are usually configured in Classless Inter Domain Routing (CIDR) notation (x.x.x.x/8, x.x.x.x/16, ... x.x.x.x/24). The largest possible Virtual Networks/SubNets is 10.x.x.x/8 and the smallest possible Virtual Networks/SubNets is 10.x.x.x/30. It is a leading practice to consider that we keep the minimum size of the Virtual Networks/SubNets at 3x plus level. While x is the size for the proposed Virtual Networks/SubNets Go-Live requirements. Virtual Networks and SubNets Size
Please note that hosting or Infrastructure as a Services(IaaS) provider may reserve additional IP Address in Virtual Networks/SubNets that one need to adjust and align for their Private Network Design.

Category: Technologies
Posted by: bagheljas
For implementing business process agility using Oracle SOA BPEL Process Manager, most books cover few of the following domains:

  • Designing and architecting SOA composite applications
  • Developing SOA composite applications using BPEL
  • Testing and debugging SOA composite applications
  • Installing, configuring, deploying, securing, and administering SOA composite applications

In this book, we have combined these domains to deliver the complete handbook. It provides our readers an understanding of what goes outside of their direct responsibilities. This horizontal understanding improves the collaboration among the cross functional groups that would result in increased team productivity. You can preview and buy the book at
Packt PublishingAmazon.comBarnes & NobleSafari Books Online
Oracle SOA BPEL Process ManagerIt is also available at LYBRARY, Computer Manuals, and most internet book retailers.

You will find an overview of technical fundamentals, step-by-step tutorials, and industry leading practices implementing SOA composite applications.

Language : English
Release Date : June 2013
ISBN : 978-1-84968-898-7
Read about in Oracle Magazine July/August 2013 Book Beat
Category: General
Posted by: bagheljas
Disaster Recovery Solutions design is driven by the following recovery objectives:
  • Recovery Point Objective: Worse case data loss is acceptable for applications for a disaster event.
  • Recovery Performance Objective: Application need to perform at the same level as primary site or we can limit user access or ok to have degraded performance for applications if disaster happens.
  • Recovery Functionality Objective: Functionality of applications needed at same level as primary site or can they operate with limited functionality.
  • Recovery Location Objective: Location characteristics such as power grid, distance relative to primary sites and corporate offices
  • Recovery Time Objective: Worse case of Time to recover for applications for a disaster event
  • Recovery Redundancy Objective: Defines the redundancy objective for the Disaster Recovery Site such as same as Primary Site or certain layer as production and while others have no redundancy

We often find that these objectives together help us define DR tiers such as Platinum, Gold, Silver and Bronze to fit into a budget to delivery DR capability for an enterprise.
Category: Best Practices
Posted by: bagheljas
Web Application Security
Category: Best Practices
Posted by: bagheljas
Best Practices for Developing & Deploying SaaS
Category: General
Posted by: bagheljas
  • App to App dependency (Internal and External) needs protocol transformation for cloud deployment
  • COTS products current license is not supported for cloud deployment
  • Gaps in Application grouping and Sequencing also known as Wave Plan and Detailed Migration Plan for each wave
  • IP based configurations that sometime even hard coded in the application code
  • Application platform components clustering protocol not supported in the cloud
  • App to Infrastructure dependency needs architecture transformation for cloud deployment
  • Application platform components and underlying middleware & operating systems has direct binding with the server hardware platform
  • Application system architecture needs to be revised for matching the current performance baseline
  • User functionality and experience impacts by network latency sometime needs to be addressed by re-design of the application architecture
  • Transformation of proprietary implementation of Load Balancers and Security Controls in WAF, Firewall, IPS/IDS etc.
  • Transformation of services/systems deployment life cycle management tools and processes such as monitoring, backup and recovery, automation (config, build, patch and deploy), ITIL etc.
 
<% %Y ()%>