Lesson 04 - EAT - Oracle

Ah yes, the lovely people at Oracle strike again!

http://www.theregister.co.uk/2016/02/24/oracle_vmware_license_headache/

This hit us about 3 months again.  Oracle has changed, or "clarified" their licensing scheme when using Oracle in virtual machines on  top of VMWare.  That clarification is that you must now license EVERY processor that could possibly run Oracle.  Which means if you have a VM that is running Oracle with 16 CPUs but is part of a VMWare Datacenter that has 1000, you now have to license ALL1000 CPUs even if your Oracle VM is set to 16.

This is actually the SECOND time I've been hit by this.  The first time was years ago when Oracle licensing went from "socket" to "core".  My Sun (which is ironic considering that Sun is now owned by Oracle) E4800 had 12 dual core SPARC CPU's and 48GiB of RAM. Which was a pretty big deal in 2006.  When Oracle changed their model it more than doubled the licensing cost (how the math worked out to more than double I don't know).  Because of the cost I had to remove one of the CPU blades which contained 4 CPUs and 16GiB of RAM.  They would not even let me keep the board installed as a "hot spare" because there was potential to use those CPUs.  Nice eh?

How does this tie into EAT?  Easy. Don't use Oracle or VMWare.  They are both greedy companies.  But seriously, knowing your technology stack and layout as well as thinking about flexibility and vendor lock-in.  I honestly do not know of a single thing that Oracle does that PostgreSQL can not do.  And there are tons of companies that offer the same level of professional 24/7 support that Oracle does.

Avoid vendor lock-in at all costs!!  Its burning my organization on 2 fronts right now.  The first is with Oracle, and the second is with a product that was built on top of vCloud Director from VMWare.  VCD is now End of Life and will be End of Support Q2 2017.  We can not buy any more VCD licenses so the functionality is now pretty much locked.  And the number of licenses that were purchased were not nearly enough for putting this product into full production because of budget constraints.  Now it is going to take a fair amount of effort to move the functionality to a new product.

Lesson04: EAT iterations and technology testing

So this is my current project.  It's the beginning of "cloud" infrastucture based on Open Stack and Ceph.  I can share this because anyone that reads about these 2 technologies will come up with this same design in all of about an hour.  EAT is another one of the pillars of EA. And like all the other pillars one of the concepts that this can not, and should not be done, as a one shot deal.  This is an interative process.  And in a lot of cases, the different pillars of a good EA program are running concurrently.

EA is generally a motivator and instigator of change.  Sometimes drastic, sometimes not.  It depends on the goals and strategy of the business, or should anyway.  In my case, with this project, it is a pretty big change to the way our infrastructure is built.  One of my main objectives is decouple from vendor lock in.  With that I would like to migrate from our VMWare infrastructure to one based, at least partially, on Open Stack and other FOSS.  The process though has to be iterative because of the nature in working a DoD environment and the strict standards we have for security.

With my project I have a phased approach because if it can't be proven and documented as secure it's sunk.  It does not matter how much faster, better, or cheaper it is, if it doesn't pass security it's dead.  First and foremost, my base OS's have to meet the STIGs[1].  This is good and bad. For one it's good because it's a very rigid set of settngs the base OS must comply with.  It can be bad based on the length of time it takes for those STIGs to be published. For example, the DRAFT STIG for RHEL [2] 7 was just released.  RHEL 7 has been out for almost 2 years.

The drawing is fairly high level.  Its essentially just the physical equipment and how they are connected.  The document it's part of drills down further.  But starting with this I was able to interface with my stakeholders and security people to determine what additional things were needed to be compliant with our IA rules.  After this I was able to create another drawing (that I can't post) showed the security devices such as Rouge Device Detectors, Intrusion Detection, Identity Management, etc.  This week I will create a services list that will include what services are running, what ports and protocols, their purpose, and who talks to who.  This is all before I even put a CD in a computer and start loading software to see if this environment will even meet the "requirements" or needs we have.

If the environment fails, it still needs to be documented so that as EAT continues work and effort is not duplicated.  Or if fixes, new software, so some other insurmountable hudle can now be mitigated and  reevaluation can be considered.  New concepts and software must constently be looked at and evaluated.  But security should not be diminished for it.  Docker is a prime example of that.  It's a great idea and works well in production.  The security of it is vastly changing though.  It's great for running Word Press sites and things of that nature, but the security is not mature enough yet to really be of use.  Red Hat and the Atomic Host Project have added a good amount of security to it via SELinux but it's still not that.  It's a maturing enviroment though and soon it will be secure enough to host more sensitive applications.

Lesson 04: The Enterprise Technology Infrastructure Architecture

The Technology Stack is without a doubt my favorite part of EA.  It is what I like doing the most and what I spend most of my work time on.  Currently I'm involved in 2 projects in this area.

The first is mapping in significant detail our current EA.  While this goes against the best practices and the thoughts of EA it is a requirement at my place of work.  Every few years we have to be reaccredited with the DoD.  This time is a little different because the way that the DoD tracks, accredits, and issues ATO's (Authority To Operate) has changed.  Spending this much time on the current state can be annoying it has brought out a few interesting things that would be somewhat like Gap Analysis.  It has also spawned a lot of discussion about where are future state is going.  And a lot of long useless meetings arguing over semantics, like the definition of "Platform".

And thats where the second project comes in and the one that I'm really enjoying.  Defining the furture state of the actual technology is a lot of fun.  I have a tremendous amount of latitude because of a lack, and by lack, I mean non-existant, of IT Governance.  Robertson's article at Gartner suggesting that ETA should not be concentrated on until other parts of the EA process are complete rings very true.  There are some cases though where pieces of it need to be defined early.  In my case a large majority of the applications in the environment are custom applications developed by us.  So certain aspects need to be defined.  Without getting into the politics too deep, we have "heavily suggested" the use of certain core services to build the applications on (we are not allowed to define, or call them standards).  For example the "preferred" relational database service is PostgreSQL.  Web servers should be either Nginx or Apache.  Messaging Services should utilize RabbitMQ, etc, etc.  Try as I might to follow the Best Practices, which I really feel they are, I am constrained by the way the DoD operates.  So due to some of the constraints and the way things operate, I'm bound by "requirements" or "stakeholder concerns" too much.  Since my primary role is RDT&E (Research, Development, Testing & Evaluation) I get dive into the ETA head first.  Since I do work closely with other groups I do try and come up with "requirements" to form my projects and their direction so that what I'm doing is seen as valuable to stakeholders or would-be/potential stakeholders or others in positions that could impact my work.  I try to use the tools and technologies they are interested in or are using (especially if I'm doing a Proof of Concept) currently.  It's a very strange world I work in sometimes and the politics can be annoying.  Again though, I get to dive head first into ETA without a lot of constraints.

I do agree with the Best Practices though and have seen a project at another organization not contrained by the DoD, crash and burn because some of these weren't followed, as well as some of the issues from Robertson.  Like not having the project and technology aligned with the business and its needs.  Another big one was "Stakeholder concerns not adequately defined".

Over all, ETA is very important.  How and when it's done really depends a lot on the company and how they operate.  It also needs to be done in a layered, iterative approach starting with higher level technologies and then drilling down.  It also needs to be documented at differently layers and levels from the high level overview for less technical people down to almost packet flow for the highly technical people.  And as always, security should be one of the major considerations and one of the first layers to be defined.