Comparing Swarm vs Kubernetes Terminology

Comparing Swarm vs Kubernetes Terminology

One of the things that my team and I are sticklers about is using the proper terminology for the proper technology. It’s just not the debate of “Principle” vs “Principal”, it’s the inferred technology that is applied by the terms you use. For instance, if a client told me they had a Docker Cluster, I might infer they are using Kubernetes, as that is correct terminology. When, in fact, they may be using Docker EE and should have used the term Docker Swarm.

Recently, when I was learning more about Docker EE Swarm at DockerCon ‘19, I started to realize the concepts are similar in Kubernetes, but the terminology was subtly different. I started to put together my own cheat sheet of similar components, so that I could keep things straight between the different sessions I attended. Now, I can speak both Swarm and Kubernetes without mingling terms, something my team will certainly appreciate!

Swarm Term Kubenetes Term Loose Definition
Swarm Cluster A group of machines that are running that provide high availability of containers.
Node Cluster Member Either a physical or virtual host that is participating within the Swarm/Cluster.
Manager Master Manages the strategy of how work is distributed within the Swarm/Cluster.
Worker (Worker) Node A participating member of the Swarm/Cluster that is providing compute capacity.
Container Container A standard unit of software that packages up code and all its dependencies, so the application runs quickly and reliably from one computing environment to another.
Task Pod A group of containers that are deployed together on the same host.
Service ReplicaSet Starts and manages the tasks/pods, ensuring the desired state.
Service Deployment Provides declarative updates to ensure the desired state is maintained.
Stack Stack A collection of services to run an application.
VIP ClusterIP Service The IP address representing the service definition.

Please contact us for your Docker needs.

CleanSlate is now a Red Hat Partner

CleanSlate is now a Red Hat Partner

CleanSlate is an IT partner who is always by your side. By working with Red Hat, the industry’s top enterprise Linux vendor, you have a partner in the planning, deployment, and maintenance of your infrastructure. Among the many offerings from Red Hat, the leading product modernizing and optimizing the IT industry is Red Hat Enterprise Linux (RHEL). Organizations in the early stages of IT modernization currently running IBM Power Servers are creating Linux LPARs to migrate workloads to Red Hat Enterprise Linux. Many other organizations who are facing high licensing, maintenance and support costs are choosing to move off legacy UNIX systems to a modern, open source Linux infrastructure in order to adopt Red Hat solutions for application development, mobile, deployment, and cloud. Migrating workloads to Red Hat Enterprise Linux – the enterprise-ready, open source operating system – improves productivity and efficiency across your enterprise IT systems and enables an agile IT infrastructure to address new business demands while significantly reducing operational costs. Red Hat Enterprise Linux maximizes the value of your existing infrastructure by introducing new technologies in an incremental, balanced way. Please contact us for your Red Hat needs.
Creating a Salesforce Process and Flow to Associate Account and Contacts During Lead Conversion

Creating a Salesforce Process and Flow to Associate Account and Contacts During Lead Conversion

Salesforce’s standard Lead Conversion leaves a lot to be desired, unfortunately.

For example, the standard conversion process does not create an association between a Contact and an Account unless you are:
1. Creating a new Account and new Contact;
2. Creating a new Contact to associate to an existing Account; or,
3. Creating a new Lead using an existing Account and an existing Contact associated to that Account.

Thankfully, they have provided the means to enhance the functionality without touching a single line of Apex. As a note, this presumes that your org is configured to allow Contacts to be associated with multiple Accounts AND that you’re expecting an Account, Contact, and Opportunity as an output of the conversion process. So, the scenario below works IF you are creating a new Account and associating it with an existing Contact (who has a primary relationship with a different Account).

Process Builder

This can be achieved by creating a Process in Process Builder for the Lead object that checks that:
– “IsConverted” flag is checked; and,
– “ConvertedOpportunityId”, “ConvertedAccountId”, and “ConvertedContactId” are not NULL.
Process Builder

Flow

This combination of fields validates that the Lead has been corrected converted and has the appropriate association with the downstream objects/records. The flow then takes the record ID of the Lead as its initial input (we created a custom field to store this value just as an internal validation). From that Lead record it returns the IDs in the “ConvertedAccountId” and “ConvertedContactId” fields. These ID values are then used to query the Account Contact Relationship object to determine if a relationship currently exists. If the answer is “No” then we create that relationship (which appears as the secondary relationship for the existing Contact). If the answer is “Yes” then we proceed to the next step.  This step makes updates to the Opportunity record (e.g., changing a field value and updating the Oppty name per a specified naming convention).

Flow

Not without an issue…

There is, however, a final scenario in which Salesforce presents a glaring bug, limitation, issue (whatever you want to call it – but it’s been submitted to Salesforce as a bug) that this Process and Flow does not cover. This scenario is when you want to convert a Lead that points to an existing Account and an existing Contact who does not have an existing relationship with the specified Account. For example,
– Contact 1 has a relationship with Account 1
– You create a Lead with Account 2 and Contact 1

During the conversion process Salesforce ignores the Account specified and substitutes in the Account that’s associated with the Contact. Bug logs, unfortunately, provide no clues as to the cause. Workarounds do exist but…they require additional fields on the Lead which, in turn, rely on user input and would require an update to the Flow to take this additional data into consideration. Hopefully (fingers crossed), Salesforce responds to my case with an update in the near future!! If/when they do I’ll post an update.

If you’d like to see how CleanSlate can help you take full advantage of your Salesforce org please shoot us an email!

Salesforce Certificate Changes in Early 2018

Salesforce Certificate Changes in Early 2018

Salesforce has recently published a news release that is relevant to all users of middleware solutions.

To uphold the best practices in Security, Salesforce has decided to rotate some certificates out during January and February 2018. Google Chrome no longer supports Symantec-issued HTTPS certifications and is now going to use DigiCert-issued certificates instead.
DigiCert
This could have an impact if you and your company use a middleware solution like Mulesoft, Scribe, IBM Broker, etc. to interact with Salesforce once the certificates are updated by Salesforce. According to Salesforce, “To test your software and middleware solutions, use //certtest.force.com as the base URL of the API login URL.

  • If you see an invalid username error or a different HTTP status code, then the test was successful.
  • If you see a certificate trust error, then the trust was unsuccessful.”

For the vast majority of Salesforce users this will have no impact on your day-to-day experience. However, companies with middleware solutions are most likely going to require some configuration updates to trust the new root, intermediate, and other relevant certificates with DigiCert.

The deployment schedule for these updates certificates are: 1) Sandbox instances during the second week of January, and 2) Production instances during the second week of February. Additional information can be found at the following site, Salesforce Certificates change from Symantec to Digicert in Jan 2018. These updates should be thoroughly tested and validated in your Sandbox instances prior to the Production deployment.

If you would like to see what CleanSlate can do for you and your Salesforce Sales and Service Cloud orgs please contact us today!

What Do Beer and Robotics Have in Common?

What 20th-century invention goes best with beer and pizza? If you answered “robotics,” you’re right! (We also would have accepted “Buffalo wings.”)

Kidding aside, the CleanSlate team recently joined other technology firms around the Indianapolis area for a program called BeerBots. This event is a joint effort hosted by TechPoint Foundation for Youth and Sun King Brewery. The two companies want to ensure “Indiana’s underserved K-12 students have access to experiential learning opportunities that inspire the pursuit of STEM careers.” BeerBots is a fun way to show the promise of their efforts and share its relevance with the technology community.

On another level, it’s a chance to relax with coworkers while nerding out and working with robotics. Over the course of the event, our CleanSlate crew created robots, drank beer, ate pizza, and teamed-up to win prizes in battle. The game is simple: Robots battle for 1 minute, with a mandatory driver change at the 30-second mark. As the rules state, “Both offense and defense are permitted during the battle, and strategy is key.” The first-place team wins a trophy. Three other teams get the Badass Award, the Nerd Award, and the Terminator Award.

If you or your company are looking for a fun teambuilding activity, contact TechPoint Foundation for Youth for more information.

 

Is Bimodal IT A Realistic Approach?

The topic of bimodal IT has been around for several years and I have a couple clients who are actually considering implementing a bimodal approach to meet the needs of a wide customer base. Upon hearing one particular client talk, with enthusiasm, about implementing bimodal for his team, I wondered if the expectations being set are truly realistic.

Gartner’s Definition

According to IT research firm Gartner, bimodal IT is “a collection of principles, capabilities, methods, behaviors, and approaches that enable an organization to differentiate the normal from the abnormal, the evolution from the revolution, the continual improvement from the disruptive innovation — and manage them differently but coherently. It’s about the business, not IT, even if in some cases bimodal starts within IT.” (Source: Gartner – Deliver on the Promise of Bimodal)

Two modes have been established, to define bimodal IT:

  • Mode 1 focuses on predictability and has a goal of stability.
  • Mode 2 is exploratory and is best-suited for areas where an organization cannot make an accurate plan because of too many unknowns.

In essence, Mode 1 operations are basically “keeping the lights on” from an IT perspective, while Mode 2 is where innovation work is performed for future design.

A Similar Example

The bimodal approach outlined by Gartner matches an experience I ran into while working as a full-time employee a few years ago. This scenario was driven by two recently promoted individuals who both reported to the CIO. In an effort to figure out how to allocate staff across these two senior vice-presidents (SVPs), the decision was made that one-half of the development team would be in charge of new application development (Mode 2), while the other half would be in charge of production support for applications that were fully deployed (Mode 1).

Perhaps, on a whiteboard or an organization chart, this sounded like a logical breakdown. One SVP handled everything in production, which included the Data Center and associated support staff, plus a development team to handle break/fix needs and minor feature requests. The other SVP would be focused on meeting the emerging needs of the business, agile and exploratory in nature, to provide solutions that were flexible and not confined by legacy decisions.

The Mode 2 team would provide innovative solutions and, once ready, they would pass the solution to a Mode 1 team, before starting work on the next innovation.

The resulting challenge for this approach is that, more often than not, the solutions designed by the Mode 2 team were not completely thought through from a production support perspective. It was like the team put on blinders and developed a solution that met the business need with a laser-focused approach. While meeting the requested need, the solution often did not fit in well with the larger IT application infrastructure. In some cases, competing frameworks and languages were selected, which had an adverse effort on the Mode 1 team attempting to support the application once it was transferred to their control. In several cases, the Mode 2 design approach was not complete, exposing a backlog of technical debt that had to be corrected as part of the first production support Sprint implemented by the Mode 1 team.

Attempts to resolve these design issues were not successful because the Mode 2 innovators always focused on the next innovation and failed to consider how their decisions impacted production support of the application. As one might imagine, this caused discord between the two modes and cultivated an environment that, though once enjoyable to work in, became challenging at best.

The core of this issue was the need to split up staff in order to accommodate two individuals who were recently promoted. As a result, changing the model wasn’t a possibility. The better approach would have been to maintain one development group. Instead of fully dedicating the staff to a given mode, rotating the roles periodically would have been a much better approach. Meaning, the team introducing a new innovation would continue to support/maintain the application, while the other team would be assigned the next new project. I have found that if the Mode 2 innovators go into the process knowing they will need to support their solutions, they are more likely to be responsible with the decisions that are made.

Alternative Views

Alternative views of Gartner’s Bimodal IT have been published. While some critics recommend staying clear of Gartner’s Bimodal IT, others are supporting Simon Wardley‘s Value Chain Mapping (VCM) concept. The approach behind VCM is almost trimodal in nature, where a value chain exists to meet the ever-changing needs of the business. As part of this chain there are three groups:

  • Pioneers – truly innovators, like Mode 2 teams in Gartner’s Bimodal IT.
  • Settlers – the missing layer – a team dedicated to refining, maturing, and stabilizing products before they are considered production-ready.
  • Town Planners – truly production support, like Mode 1 teams in Gartner’s Bimodal IT.

The following diagram, courtesy of Simon Wardley, demonstrates how Value Chain Mapping fits into meeting the needs of the business:

Image title

Keep in mind, the chart above is simply one step (out of ten) in Simon Wardley’s “How to get to Strategy” publication, which I recommend reading when time allows.

In my experience, larger corporations have placed the pioneer need into the hands of enterprise architecture (EA) staff. The EA team maintains the responsibility to innovate, making sure their innovations have the ability to work within existing IT infrastructures. A challenge to this approach is that the burden can be too much to place on the settlers – since they are not always approaching the solution with the same mindset as the pioneer. The pioneer’s vision is one of enterprise scale, while the settler has a focus on meeting the current need of the business. So, even in a trimodal (or VCM) approach, challenges should be expected.

Conclusion

I understand there are individuals who thrive as innovators and there are individuals who enjoy their focus on providing production support. However, for a majority of those in Information Technology, there is a desire to participate across both ends of the spectrum. It is important to understand the background, goals, and traits of your staff before trying to place them into positions which are not a solid fit, based on their skills, abilities, and ambitions.

Since an IT department’s greatest investment is the human resource expenditure, the decision to implement bimodal, trimodal or nonmodal (I just made that up) should be driven by the people who will actively live in that mode. Making the incorrect decision and hoping for a positive result is no different than trying to place a round peg in a square hole.