You have reached the Trail Head for my technology exploration trail. I am Anand Rao , Currently working as a Field Technologist for Tanzu at VMware.
My Journey on technology has brought me through multiple industries and places, giving me the previlege of meeting some amazing people. There is an ever growing list of new things to learn in technology and life in general.
The Cluetrail is my effort on chronicaling the journey, the breadcrums of my journey with a hope that it helps solve problems and overcome challenges with a clue or two.
The Clue Trail is my writing while the Clue Cast is my video Blog. Looking forward to build out more content here on my web home as I continue to build the Clue Trail.

Recent Blog posts


The "all in" Kitchen Sink ...or Not !

The Art of Org and Space Management in PCF.



Image result for kitchen sink full
We have all seen this in our kitchen 


A Quick introduction: Pivotal Cloud Foundry provides a collaboration model with isolated workspaces for Application deployment and management. The virtual allocation of workspaces follows a hierarchy of Organizations and spaces inside them.

The Org ( Organization)  is  controlled by a Role Based Access Control ( RBAC)  which is used to controls Quota management for each org by the operators as well as controlled Access to Users within the Org to perform specific actions.

A Space is one of many isolated workspaces(space), created within the Orgs by the Org users (collaborators) to deploy and manage applications. By default the applications deployed in the spaces are isolated and so are the the services that are created within the spaces. This means, by default all services created inside a space are allowed to be bound to apps inside the same space. This is true even to instances of Spring Cloud Services, unless  you have adopted Spring Cloud Services 1.2 . SCS 1.2 comes with Multi-Site Service Discovery which can be applied across different Orgs on the same PFC foundation as well as across Foundations.

Now , Lets look at this in a different perspective. Folks have followed the rule where, a particular team uses a single space for all its applications. This is where the kitchen sink analogy comes into picture. Having potentially 100s of apps in a single space becomes a little unmanageable. Even though this does not have a direct impact on app placement across AZs and the use of affinity rules,  the clutter of of too many criss-crossing apps that call one another all deployed within a single space is not a pretty picture.

This is when I want to introduce the concept of Apps in a Box. Think about a set of microservices (apps) that form a logical application by interacting with one another and with the services that they potentially share. This, of course will need them to be able to discover each other's instances.

Based on my experience and talking to multiple folks who have been there,  I think ,  the best logical organization of Orgs and Spaces as follows:

  • Real Organizations of teams that work on a platform ( group of common Applications) should be grouped into Orgs. 
    • The Collaborators in those Orgs should have access to see( read)  all the Spaces to help with cross team collaboration.  
  • Spaces would make perfect sense  for a Single App in a Box ( should we say App in a Space ? )
    • On the development foundations ( I have seen customers use  Orgs for Environment Separation like Dev vs QA vs Stage),  you would be giving the Space Developer and Manager access to the developers who are actively working on the Apps that form a logical group. 
    • In the spirit of being totally cloud native,  we should always insist on using a discovery process to find microservices that are needed as upstream services. 
    • Non-Development ( see how I don't talk about prod and non-prod here ) , should always get the app deployments via pipelines triggered by Code commits or  other triggers and should always  use a cloud foundry user ID  created specifically for use by the pipelines. 
    • The Developers should not be given access to the Orgs and Spaces running non Development workloads. 
    • Tests  should be automated and executed via pipelines. 
    • Multiple Data Flavors could be ingested for running different sets of focussed tests.  
    • With Autoscaling in place ,  we should execute our automated performance tests as part of the same pipeline as well. 
With the above way of Organization ,  one would get a clear logical grouping.  This would also mean  that the same collaborators could be part of the development lifecycle of multiple Apps in a Box and thus have a role on multiple spaces. But from a Security and control perspective ,  the apps are built and deployed in the application perspective rather than the Team that builds them. 

Another major advantage of using the pipelines approach is that it automates all kinds of tests be it functional and unit tests  or the performance tests  that trigger huge but short term application scaling allows you to convert all the infra used  for the pipeline execution as ephemeral.  Once the tests are completed,  you can and should do a
 cf delete
on all the apps that form that box.  This approach has helped reduce substantial infra needs at customers and helped promote hands off pipelines and eliminate the Works on my computer syndrome. You leave behind a clean space and a well managed Org on Cloud Foundry.  The Operators will be pleased that their clean up scripts will not find forgotten ,  left behind apps and services. 

This should leave your kitchen sink looking like this :) 

Related image
Who would not want this ??




Read More

The Trail .....

Reviving my blogging habits. This time over,  I find a compelling motivation to journal my path through the amazing Technology Journey I have embarked on. One that helps Businesses change their way of building software and adopting the ever changing landscape of the Cloud.

Working as an Enterprise Architect at Cengage Learning , I got this amazing opportunity to get involved in what I call a movement ! Pivotal. The wide spectrum of pivotal's offerings, all the way from the Spring Framework to the Pivotal Cloud Foundry where  Spring Apps run the best,  Pivotal's  products and the amazing people set me on the journey to help companies change the way they build software. After setting the Cengage Ship Sail on its Cloud native journey to adopt PCF,  I took on a position with Pivotal's Platform Architecture team on the west coast based our of the SF Bay Area.

The technology challenges and solutions being worked on at multiple high quality amazing companies gives me a totally new perspective on how I want to help companies and businesses change the way they build,  deploy and manage software.  #disrupt #innovate #learn  #iterate

I am planning to use this Clue trail as a way to chronicle my Trail through the Tech exploration as I find Clues to solve simple and complex technology problems.

Read More