Thursday, June 9, 2016

Today's Cloud Architecture

Automating deployments with Constant Integration (CI) and Constant Deployments (CD) have improved our Software Development Life Cycle (SDLC) dramatically.

Most corporations doing any software development have figured out that it is better to integrate changes early. It reduces risk and helps find issues earlier in the life cycle.

Here is a typical Cloud Architecture for software deployed to "The Cloud":
This was acceptable Cloud Architecture last year.


  • Build Automation
  • Github workflow (pull requests & code review)
  • Constant Integration (to the "cloud")
  • Constant Deployment (via Bamboo)
  • Managed Releases (integrated with Jira tickets)

Q: What's wrong with that picture?

There are quite a few areas for process improvement requiring a different way to approach application development, testing, deployment and monitoring.

Answer: A lot

  • Heterogeneous Development Environment
  • Time Consuming Build Process
  • Time Consuming Deploy Process
  • Stateful Ansible/Chef/Puppet Packaging
  • Code Complexity
  • Extra Image Creation Time
  • Costly Server Startup Time
  • Manual or Roll-ur-own HA

There are a lot of inefficient, stateful, slow, not-easily-repeatable parts to the way many cloud deployments are done today.

Stateful Ansible/Chef/Puppet Packaging

Notice that output files of one software package are inputs to the other software packages, making our solutions complex and non-deterministic.

Questions For You to Ponder...

  1. How does your company manage it's Software Development Life Cycle (SLDC)?
  2. How long does it take from the time you get a feature request (or bug report) to a delivered solution?
  3. How well utilized are the CPUs of your computing resources?
  4. How resilient are your applications to failure?
  5. Can you handle rolling software deployments?
  6. How much complexity and technical debt is your company's IT infrastructure running on?

Disruptive Innovation

There are a lot of inefficient, stateful, slow, not-easily-repeatable parts to the way many cloud deployments are done today.

Arguably the most exciting area of improvement is the change to the way the developer's workstation is configured.

The same immutable server environment that has been hardened for production is leveraged for the developer (and used throughout all environments).

Declarative, portable, disposable and environment variables configured.

That's Disruptive Innovation.


This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Thursday, April 28, 2016

Search and Replace

Here's a quickie, but goodie...

sed-i -e "s/alice/bob/g" data.json

That will replace every instance of "alice" with "bob" in the file, data.json

This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Wednesday, April 13, 2016

Page Up & Down in VIM and ITerm2

Sometimes I just forget the easy stuff...




PAGE UPfn+Command+UpArrow
PAGE DOWNfn+Command+DnArrow


This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Wednesday, March 23, 2016

Docker Ecosystem

Docker is a containerization platform that is used to develop, distribute and deploy applications in a portable and predictable way.

It accomplishes this by packaging components and their dependencies into standardized, lightweight process environments called Docker containers.

Docker containerization is especially useful in distributed systems, where there is a need to scale automatically, based on configuration profiles and resource utilization.

After 3 years, a lot of software has been developed around this containerization platform. See diagram below.

Containers v. VMs

Containers are much lighter than VMs.

Whereas VMs require a separate, entire guest operating system for each VM, Docker containers only require a single Docker Engine per workstation and all that is packaged in the container are the applications and their direct library dependencies.

Development/Deployment Implications

Now, we're finally able to configure develop our microservices in a Docker container in our local development workstation.

We can tune our apps locally and have confidence that our deliverables that are deployed via our continuous integration and continuous deployment processes are consistent with our dev environment.


This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Thursday, February 18, 2016

Golang Pointers on the Heap

In this post we'll delve into the differences between the Stack and the Heap and decompile some Go code to see how the new function allocates space on the heap struct and returns its 8 byte pointer.

The Stack

The stack is the memory that is used to store local variables for a executing process's thread.

When a function is called, a block is reserved on the top of the stack for local variables and some bookkeeping data.

When that function returns, the block becomes unused and can be used the next time a function is called.

The stack is always reserved in a LIFO (last in first out) order; the most recently reserved block is always the next block to be freed.

This makes it really simple to keep track of the stack; freeing a block from the stack is nothing more than adjusting one pointer.

Note that in Golang, there is a stack per goroutine.

The Heap

The heap is storage space in RAM set aside for dynamic allocation.

Unlike the stack, there's no enforced pattern to the allocation and deallocation of blocks from the heap; you can allocate a block at any time and free it at any time.

This makes it much more complex to keep track of which parts of the heap are allocated or free at any given time; there are many custom heap allocators available to tune heap performance for different usage patterns.

Note that in Golang, the new keyword always allocates on the heap.

Escape Analysis

In some cases the compiler follows rigid rules (like "new always allocates on the heap") and in others the compiler does "escape analysis" to decide if an object can live on the stack or if it must be allocated on the heap.

Code Example

When we compile the code below...

package main

func main() {

type DemoStruct struct{}

func demoFunc1() (*DemoStruct, error) {
 var data *DemoStruct = new(DemoStruct)
 return data, nil

Generate Plan 9 Assembly Code

$ go build -gcflags "-S " heap.go

"".demoFunc1 t=1 size=96 value=0 args=0x18 locals=0x10
 0x0000 00000 (heap.go:8) TEXT "".demoFunc1+0(SB),$16-24
 0x0000 00000 (heap.go:8) MOVQ (TLS),CX
 0x0009 00009 (heap.go:8) CMPQ SP,16(CX)
 0x000d 00013 (heap.go:8) JHI ,22
 0x000f 00015 (heap.go:8) CALL ,runtime.morestack_noctxt(SB)
 0x0014 00020 (heap.go:8) JMP ,0
 0x0016 00022 (heap.go:8) SUBQ $16,SP
 0x001a 00026 (heap.go:8) FUNCDATA $0,gclocals·0528ab8f76149a707fd2f0025c2178a3+0(SB)
 0x001a 00026 (heap.go:8) FUNCDATA $1,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB)
 0x001a 00026 (heap.go:8) MOVQ $0,"".~r1+32(FP)
 0x0023 00035 (heap.go:8) MOVQ $0,"".~r1+40(FP)
 0x002c 00044 (heap.go:9) MOVQ $type."".DemoStruct+0(SB),BX
 0x0033 00051 (heap.go:9) MOVQ BX,(SP)
 0x0037 00055 (heap.go:9) PCDATA $0,$0
 0x0037 00055 (heap.go:9) CALL ,runtime.newobject(SB)
 0x003c 00060 (heap.go:9) MOVQ 8(SP),BX
 0x0041 00065 (heap.go:9) NOP ,
 0x0041 00065 (heap.go:10) MOVQ BX,"".~r0+24(FP)
 0x0046 00070 (heap.go:10) MOVQ $0,"".~r1+32(FP)
 0x004f 00079 (heap.go:10) MOVQ $0,"".~r1+40(FP)
 0x0058 00088 (heap.go:10) ADDQ $16,SP
 0x005c 00092 (heap.go:10) RET ,

Note that Go linker inserts some assembly code to support segmented stacks

Analysis shows the pointer to the struct escaping; The compiler allocated memory for the struct of type DemoStruct on the heap and returns its address in the form of an 8 byte pointer.

Since this is an 8 byte pointer MOVQ 8(SP),BX, we know that we're running on a 64 bit operating system

$ uname -a
Darwin venom 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64

If we were running this in a 32 bit operating system, the pointer would get 4 bytes of storage space.

Escape Analysis of Variable Not Escaping

Because the numbers slice is only referenced inside Sum, the compiler will store the 100 integers for that slice on the stack, rather than the slower heap.

There is no need to garbage collect numbers, it is automatically freed when Sum returns.

This is just one example of how Go is intelligently designed for speed.


This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Friday, October 30, 2015

Java Applets Don't Run In Chrome Browser

Have you noticed that some web pages have previously dynamic sections that no longer work in Chrome?

Have you seen a message stating, "Chrome no longer supports NPAPI"?

That's because the Chrome Browser no longer supports java applets... and for good reason: Running java applets in your Chrome browser is a security risk.

Options for the Die Hards

If you are determined to run that web page with that non-functional java applet, regardless of it's security implications, you have options:

Run Java Applets By

  • Using a browser that still supports NPAPI (MS IE, Safari, Firefox)
  • Use the IE Tab plugin for Chrome (for Windows platform)
  • Convert Java Applet to a Web Start application (if you can influence development)


Google's Chrome version 45 (scheduled for release in September 2015) drops support for NPAPI, impacting plugins for Silverlight, Java, Facebook Video and other similar NPAPI based plugins.

Netscape Plugin Application Programming Interface (NPAPI) is an application programming interface (API) that allow plug-ins (more specifically, browser extensions) to be developed for web browsers.

It was first developed for Netscape browsers, starting in 1995 with Netscape Navigator 2.0, but was subsequently adopted by other browsers.

In NPAPI architecture, a plugin declares content types (e.g. "audio/mp3") it can handle. When the browser encounters a content type it cannot handle natively, it loads the appropriate plugin, sets aside space within the browser context for the plugin to render and then streams data to it. The plugin is responsible for rendering the data. The plugin runs in-place within the page, as opposed to older browsers that had to launch an external application to handle unknown content types.

NPAPI requires each plugin to implement and expose approximately 15 functions for initializing, creating, destroying and positioning plugin content. NPAPI also supports scripting, printing, full-screen plugins, windowless plugins and content streaming.

Full privileges are only granted by default to chrome scripts.


Mozilla is deprecating all plugins.

"Plugins are now a legacy technology. They are not available on most mobile devices. Mozilla encourages website developers to avoid using plugins wherever possible. If there are plugin features which are not available in the web platform, we encourage developers to post their use cases to project list, so that Mozilla can prioritize web platform work to make those use cases possible."

Note that plugins are shared libraries that users can install to display content that the application itself can't display natively. For example, the Adobe Reader plugin lets the user open PDF files directly inside the browser, and the QuickTime and RealPlayer plugins are used to play special format videos in a web page.


If you developed a java applet for a web page and deployed it to production, you might want to keep fact that off your resume.

Running java in a web browser was never a good idea.

The java applet is executed within a bloated Java Virtual Machine (JVM) in a process separate from the web browser itself. The java plugin was designed to run the java applets in a "secure sandbox" in the browser. This would supposedly prevent any java applet from presenting security risks to your computer.

The reality is that there have been so many vulnerabilities that allow nefarious Java applet code to escape the sandbox and exploit your system that Oracle has basically given up.

Java will no longer run unsigned applets, unless you go to the trouble of reducing your browser's default security settings. Running unsigned applets shouldn’t be a problem if the security sandbox were trustworthy in the first place. Right?

Furthermore, the graphics generated from Java apps, IMHO, never were crisp and/or visually appealing.

Cisco’s 2014 annual security report claims that 91 percent of all web attacks in 2013 targeted Java.

Running java applets in a browser will be insecure, slow, have high resource requirements and look sub-par; So, don't do it.


This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Wednesday, October 28, 2015

The Hand-Crafted SQL Anti Pattern

You probably should have used an ORM if...

  • your app has a lot of SQL statements that exceed 200 lines
  • you use multiple CTE (WITH Clauses) to deal with the complexity of your looong SQL statements
  • you frequently implement helper functions that return SQL clauses
  • you frequently refactor your helper functions that return SQL clauses
  • you find it takes more time to add functionality to your SQL queries than it took to design the database DDL, indexes and write that super long SQL in the first place

Those are a few indications of deeper issues.

Before you discount the "exceed 200 lines" or "multiple CTE" items, please consider that the reason for having sql helper clauses is typically to reduce the complexity of the sql statement; If the sql statement needs simplification then odds are it's too darn long; Hence, the "exceeds 200 lines" and "multiple CTE" remarks.

Another rule of thumb of mine... If any logic (any language) exceeds 150 lines long, it's probably too long and should probably be refactored.

Technical Debt

With a lot of hard coded SQL, you'll likely encounter problems down the road like...

SQL Errors you might get with Pagination

In this case, we were using a WITH clause and wanted to enforce a new sorting order...

ERROR:  SELECT DISTINCT ON expressions must match initial ORDER BY expressions
LINE 52: select distinct on (
********** Error **********

ERROR: SELECT DISTINCT ON expressions must match initial ORDER BY expressions
SQL state: 42P10
Character: 1213

We learn by ERROR that when we try to add the flexibility of changing the sort order, we have new, unforeseen problems to solve which are a direct result of our legacy, hard-coded SQL.

Reasons to use a lot of hard-coded SQL, instead of an ORM...

  • Your business objects are not easy to map to database tables
  • Your application needs lot of complex, hand-tuned SQL
  • You use a lot of stored procedures and complex logic in your database

If this is your case, you should probably revisit your database design and Data Manipulation Language (DML) implementation strategies and actively reduce your technical debt before you are asked to maintain all that hard-coded SQL.

Intelligent enterprise application design begins with information architecture and a solid database design.

If you frequently feel that it takes a lot longer to add functionality to your application than it should, you should closely examine your application architecture.


Q: Am I saying that you should always use an ORM to solve your all of your DML needs?

A: No.

However, I am saying that if the vast majority of your DML code is hard-coded SQL, you should probably find a good ORM that fits in your technology stack and learn how to use it.


None. That's just my hard-knock experience speaking.

This work is licensed under the Creative Commons Attribution 3.0 Unported License.