About Me

My photo
Rohit is an investor, startup advisor and an Application Modernization Scale Specialist working at Google.

Friday, January 29, 2016

Cloud Foundry in a Box


You may be wondering how do I hitch a ride on the PaaS train. You would like to spin up a Cloud Foundry on your local machine in less than 10 minutes ? Let me present to you Micro Cloud Foundry aka cloud in a box brought to you by the Cloud Foundry Foundation:

MicroPCF is the simplest way to get a complete Cloud Foundry on a single machine
You gotta verify this. So head on over to https://github.com/pivotal-cf/micropcf and spin up Cloud Foundry in a VM using vagrant. The Future of MicroPCF is bright. From the release notes

In addition to the standard Cloud Foundry components, the MicroPCF distro will include the default PCF service brokers (Redis, MySQL, and RabbitMQ), as well as other PCF-specific applications. The first service available is the Redis service broker. This allows Redis instances to be created and bound to apps running on MicroPCF. More information can be found on Redis for Pivotal Cloud Foundry.
WOA! Services and a full featured platform all in one VM.

Thursday, January 28, 2016

Mendix loves Cloud Foundry

In June 2014 Mendix app platform (aPaas) married Cloud Foundry (PaaS). In case you are wondering if this announcement was just vaporware please rest your concerns. Mendix apps work on Cloud Foundry. Kaushik Bhattacharya has done all the legwork to flush this out. Read below ... 

Mendix buildpack documentation describes the steps to push the application. The short version is:

1> cf push mendix_app -b https://github.com/mendix/cf-mendix-buildpack -p <mendix_app.mda> --no-start

2> Create and bind PCF MySQL service to the app in the usual way.

3> Create and bind PCF RiakCS service to the app in the usual way.

4> The app expects values for two variables ADMIN_PASSWORD and DATABASE_URL which can be set as follows:
cf set-env my-app ADMIN_PASSWORD password
cf set-env my-app DATABASE_URL ‘mysql://username:password@hostname:port/database’
Note: You can copy-paste the database URL from the VCAP_SERVICES variable but all parameters such as “?reconnect=true” have to be removed.

5> Restage/start app:
cf restage/start my-app

That's it! 

Cloud Nativeness of an Application

Questions to determine the cloud readiness of your  application to move to the cloud

Q0 - Pick an appropriate path to the cloud:
    1. Java Buildpack
    2. TomEE Buildpack
    3. JBOSS Buildpack
    4. Liberty Buildpack
    5. WebLogic Buildpack
    6. Fat jar (Bundle app server with app)
    7. Docker





Q1 - Does the application rely on persistent file system ? Do you expect the file system to persist across restarts.
     - Disk Caches
     - Transaction Logs
     - Harcoded File Paths
     - Any java.io.* use needs to be looked at

Q2 - Does the app rely on non HTTP inbound protocol routing.
    - TCP support coming in the near future

Q3 - Does the app take a long time to start or stop
    - any dependencies or semantic ordering between apps

Q4 - Does the app use any native code libs  
    - Those libs need to be recompiled for the PCF Stemcell

Q5 - Does the app require distributed XA 2-phase commit transaction ?

Q6 - Is the app packaged as an ear/war/jar file ?
     - JBOSS buildpack and java buildpack do not support ear files

Q7 - Configuration - How is the app configured.
     - Hardcoded property files
     - Generate one artifact configured based on the environment
     - Where is the config coming from

Q8 - All logging to stdout/stderr
    - No log persistence
    - Use Console appenders

Q9 - What do you use for monitoring today
  - Any agents installed on the OS wont work
  - Agents have to bundled with the app or the app server or the buildpack

Q10 - Size of app should be ideally less than 250MB
    - More than that then you have issues with scaling and cf push

Q11 - Favor external caching instead of in-jvm Caches
      - all caching should be done in a distributed cache outside the app JVM
      - in-JVM caches are transient
      - all state to be managed outside the app via backing services
        - punch firewall holes for all backing services

Q12 - Libraries and Frameworks
    - Use cloud native / cloud friendly frameworks like Spring Cloud etc.?

Q13 - Does your app need specialized hardware in terms of specific CPU/Memory/Disk resources
    - Dependency on specific JVMS/JDKs ?

Q14 - No app server specific HA/Clustering or Administration will work in CF

Q15 - OS based registry security will NOT work on the cloud
    - Rely on  3rd party trust protocols like OAuth or SAML or Authentication and Authorization ?