Breaking Up the Monolith

Tech Skills

In our first post of this series, we looked at how microservices help you build applications with an eye towards the future. And in our second post, we took a deep dive into how microservices work. But what if you currently have a monolithic application? How do you know if it’s time to move to…

In our first post of this series, we looked at how microservices help you build applications with an eye towards the future. And in our second post, we took a deep dive into how microservices work. But what if you currently have a monolithic application? How do you know if it’s time to move to microservices? And if so, how do you get there?

As we mentioned before, knowing why to build a microservice is only half the battle. Knowing when (or when not) to build one can be a trickier question. There’s no one size fits all. That said, there are a few questions you can ask to help decide if you’re ready for microservices. We’ll explore them in this final post of our series.

Reading the Signs

Is your organization or team experiencing exceptional growth in both employee base and technical stack?
As a codebase grows to a certain size, more people are needed to maintain it. But anyone who has worked on a single codebase with ten other engineers knows the struggle of dealing with merge conflicts during code reviews. If a team is losing valuable time trying to resolve conflicts, it might be time for microservices. Microservices help distribute development teams more efficiently, as complex backend systems can be built faster by dividing workloads into multiple small teams, with each team responsible for a given set of microservices.

Is your application down often?
Every time you deploy an application, it breaks. Or the backend system is seemingly down all the time for maintenance. If these scenarios sound all too familiar, it might be time to shift from a monolithic architecture to microservices.

Are you having difficulty scaling hardware to optimize application performance?
Larger and more complex applications require additional hardware to perform well. Some parts of an application might put more demand on the hardware than others, and the whole application can face degraded performance due to a single poorly-performing feature. Microservices allow individual units of business logic to be assigned their own dedicated hardware, and they can be scaled independently of other services. A slower-performing process can be isolated and capped to a fixed about of CPU, memory, disk, and network bandwidth, which means it can’t steal resources from other features.

Choosing the Moment

Once you’ve decided to build a microservice, the next questions are when to build it and when to switch over. That’s a hard question to answer for any organization. The monolith architecture works for small applications and small engineering teams. But when does the monolith stop working?

It turns out growth is often the death of the monolith. Organizations in the process of undergoing exceptional growth, in both the employee base and in technology stack, can achieve that growth by switching to microservices. If the engineering team is losing valuable time resolving merge conflicts, then it might be time for microservices. If the growing backend system is down all the time for maintenance, then microservices might be the answer. The answer of when to build a microservice is when growth is expected.

Hardware provides a great example of this, as it can only be scaled horizontally so much. Maybe those high-CPU and high-memory servers are too expensive and too underutilized during non-peak hours. The cloud is becoming more appealing with the ability to provision hardware as needed, and smaller servers with lightweight workloads become easier to bring up and tear down in response to changing demands. Microservices have lower hardware requirements, and they can start up quickly to meet peak demands.

Making the Move

Monoliths present a number of challenges that you’ll need to tackle in the move to microservices. A monolith has a tendency toward tight coupling of components, as well as stateful behavior. The application was never intended to live as separate and isolated components working in concert to make a system. The monolith may also be rooted to the infrastructure it lives on, depending on system resources such as a local filesystem and network. What’s more, you need to keep everything up and running during the transition. So how do you move to microservices? Let’s break it down.

Step 1: Determine Your Domains

Your first task is to look at all the features of the application and organize them into logical business units, or domains. For example, your application may have major features related to login/logout, user data, and session management. These features can be logically organized into a single business domain called Authentication. Repeat this step for all of the other domains in your application.

Step 2: Prepare the Monolith

Next, get your application ready for the big break up. To do this, decouple components within the application along the lines of the business domains you came up with. This will result in a number of edge and middle modules within the application, each dedicated to a particular domain, like our Authentication example. You’ll also need to move stateful in-memory stores into shared datastores. Finally, put a router in front of the monolith to smooth the rollout of microservices.

Step 3: Work From the Bottom Up

As you begin breaking out microservices from the monolith, it’s always best to start at the bottom and work your way up. First, create a separate database to store data for the domains you are moving to microservices. Next, break out the data access modules that access this data into middle microservices. Finally, break out edge modules that consume this data into edge microservices. When everything’s ready to go, use the router to toggle redirection to the new edge services. Keep repeating this same process for each domain until all of your modules are broken out and the monolith is no more.

In the diagram below, the Login, Users, and Sessions modules were decomposed into modules within the monolith, and then broken out as separate microservices.

breaking-up-the-monolith

One challenge you’ll encounter during the transition is the need to support both the microservices and the monolith side by side. That also means duplicating work, as you’ll often have to make changes or fixes in both places. The good news is that organizing your monolith similarly to your microservices makes it easier to copy-and-paste code between them.

Conclusion

If your application and organization are both set for growth, microservices can help you meet the challenge of building modular, scalable, highly-available solutions. When you’re ready, you need to organize your application’s features into domain-specific modules, then break them out one by one.

Just remember that transitioning from a monolith won’t happen in a single overnight deployment. You need to strategize as you cherry-pick domains out of the monolith. The key is to complete the transition to microservices and not leave your application in limbo. If you’d like to learn more about how to make the move to microservices, or if you need some help, feel free to ask us. That’s what we’re here for.

Kenzan.IO: A Guide to a Website From Scratch

Tech Skills

In the quickly evolving world of front-end development, it can be overwhelming to choose from the multitude of frameworks. It is, by extension, downright baffling to build a whole project from scratch – which is exactly what we did for Kenzan.io. In this article we’ll walk through the technologies we chose, why we chose them,…

In the quickly evolving world of front-end development, it can be overwhelming to choose from the multitude of frameworks. It is, by extension, downright baffling to build a whole project from scratch – which is exactly what we did for Kenzan.io.

In this article we’ll walk through the technologies we chose, why we chose them, and what we thought.

Kenzan .IO Scope
Before diving in, let’s take a look at the scope of the project. We needed to build a fast, sleek, and responsive website that could integrate with other Kenzan sites. The website also needed to be easily updated by our marketing department. Kenzan.io was simple in terms of business logic, with very little state maintained, and most of the complexity held in the views.

Front-End Architecture
This leads into our first design decision: React for our front-end view library. React gave us the scaffolding we needed to design component-based views within a single page application without weighing down the project. Most importantly, React’s one-way data binding paired with the virtual-DOM made our image and animation rich site run with impressive speed on all browsers. We styled our views using Sass, to take advantage of variables, mixins, and other advanced CSS features. The Sass was compiled down to CSS in our build process and vendor prefixes were added using Auto-Prefixer. These few pieces led to fast and aesthetic pages.

Since React only handles our views, we needed a way to handle the model and controller portions of our front-end. We decided to use React Router for our SPA routing, jQuery for advanced DOM interaction and HTTP calls, and ES6 for all other business logic in the site. React Router has quickly gained steam as the widely accepted routing package for React applications, and we found it easy to learn and incorporate. We combined React Router, jQuery, and vanilla JS to build a scroll based navigation for the website, called scroll jacking. This feature is often handled with CSS and HTML sections but we decided to incorporate it into a single page application architecture by pairing scrolling with view routing. We also used jQuery to handle our AJAX calls because the library was already present in the project. For the sake of learning, a dive into Fetch or Thunk would have been interesting, but ultimately would have added unnecessary weight to our application. Finally, we chose ES6 over ES5 for all the new features including JavaScript modules, arrow functions, and classes. With the help of the very opinionated AirBnB style guide, we found ES6 syntax to be more concise when compared to ES5. We compiled our ES6 using Babel and handled module loading with WebPack streams in our Gulp build process. Both libraries had fairly simple configuration and no work required once the boilerplate was assembled.

Back-End Architecture
With our front-end architected, we began looking at ways to integrate Kenzan.io with our other Kenzan sites and make it friendly for marketing updates. Since all Kenzan sites are WordPress sites and our marketing team is very familiar with the WordPress content management system, we decided to pursue the bleeding edge WordPress API. With the API, all data was entered, stored, and retrieved from the Word Press CMS, and we had access to data from all of Kenzan’s pages. Most importantly, we found the WordPress API extremely easy to use. The API had good documentation, was straightforward to integrate into a single page application, and updating content was quick and easy.

Testing
We saved the best for last with unit testing. This does not follow test driven development, but for the sake of time constraints, we wanted to get all content on the site before testing so we could evaluate time remaining before making a testing plan. When we found ourselves with a couple weeks left, we decided to branch out again and try a new test runner called Ava. The allure of Ava is the ability to run unit tests concurrently, each test with an isolated scope in a separate Node thread. This means no interference between tests with faster test suite execution. For pure JS, we tested with Ava and Sinon, used for spies and stubs. For React components, we paired Ava with Enzyme, an extension of ReactTestUtils, and BrowserEnv, for a virtual browser in Node. This trifecta allowed for quick and seamless testing of our React components, including rendering the DOM, testing lifecycle methods, updating the state, and re-rendering the component. All the testing libraries had very little boilerplate code to get started and were easy to work with when writing the tests.

Finally, we wanted to add a last layer of confidence with a suite of E2E tests. Prior to this project, most of our front-end development experience had been in Angular with E2E testing handled by Protractor. Unfortunately, Protractor is not friendly with React so this was another chance to learn something new. We found an E2E library called Nightwatch.js that integrated with React and ran off Node, making configuration and execution not too different from Protractor. The creation of these tests was handled by our QA team, and is a topic for another blog post, but their inclusion helped ensure no bugs made it out to production.

The Final Product
After six weeks, and many scrums we met our goal of delivering a responsive, performant website with a WordPress back-end and full unit and E2E test suites. However, our most important accomplishment was diving deep into new technologies and expanding our knowledge here at Kenzan.

To checkout the website, click here: http://kenzan.io


The author of this post is Marie Schmidt, at junior front-end developer at Kenzan. She’s featured as our employee spotlight.


We’re looking for some  talented developers, architects and engineers to help us build more cool stuff like the Million Song Library. Click here to see open positions.

 

Making Microservices Work

Tech Skills

In our first post in this series, we showed how microservices can help you architect applications with the future in mind. Knowing what a microservice is, and what purpose it serves, is a big part of building a successful architecture. But to truly fit your business needs and meet your goals, understanding the variations of…

In our first post in this series, we showed how microservices can help you architect applications with the future in mind.

Knowing what a microservice is, and what purpose it serves, is a big part of building a successful architecture. But to truly fit your business needs and meet your goals, understanding the variations of microservices is key.

While there is no precise way to define the architectural style of microservices, by looking at specific characteristics, we can better understand what makes an application a microservice. In this post, we’ll go into more detail about how microservices work, and how to make them work for you.

How Big is Micro?

You can build what you think is a microservice, but actually, what you have just created is a distributed monolith. Individual applications become so coupled together that we start referring to them as a single noun. In other cases, we end up seeing microservices get so large that they themselves become monolithic, resulting in a monolith army.

The size of a microservice isn’t determined by the number of lines of code or the amount of functionality, but by the amount of volatility a microservice has—the amount of change that is expected to occur over the life of a microservice. If changing one microservice also requires changing another microservice, it means those microservices have been incorrectly decoupled from one another and should instead be combined. On the other hand, if a microservice is composed of features that are fundamentally dissimilar and volatile, it means those features have been incorrectly coupled together, and they should instead be split up.

In a nutshell, features of a microservice should be grouped by similarity and the likeliness of change. If changes to a microservice keep causing backwards incompatibility or constantly require refactoring, it probably needs to be decomposed into multiple microservices.

Life on the Edge (and in the Middle)

Another part of defining a microservice is understanding what the types of microservices are and the rules they should follow. These can vary depending on your architecture. One architectural solution we’ve employed with success defines two types of microservices: data-driven services in the middle and business-driven services on the edge.microservices-cloud-architecture

Middle Tier: Driving Data

Data-driven services are called middle tier services, which are solely assigned and are responsible for a single data source. In this architecture, the only way to access any given data source is through the corresponding middle tier service. These are assigned to a single data source, so that if one data source goes down, it will not take the other services with it in the event of an outage. The only responsibility of a middle tier service is to make data available to other microservices. This could also mean applying caching or fallback scenarios to keep the data flowing.

Edge Tier: Driving Business

We refer to business-driven services as edge tier services, which drive the business logic of an application. Edge tier services typically exhibit the most amount of volatility-based decomposition, as business logic for each edge tier service can vary greatly depending on the systems it supports.

While choosing when to build a middle tier service is easy (if you have a data source, you need a microservice to go with it), choosing edge tier services requires more attention to the amount of volatility in the business logic. Functionality is driven by edge services, and in this type of architecture the number of edge tier services will always be greater than the number of middle tier services. Edge tier services connect with one or more middle tier services, but typically won’t connect with another edge tier service. In this particular solution, proper decomposition of microservices based on volatility shouldn’t require edge services to depend on other edge services, or middle services to depend on more than one data source.

While we’ve put this type of architecture to good use, other solutions are certainly possible—more on that in a bit.

Finding Each Other in the Cloud

Deploying microservices to the cloud enables clusters of microservices to be scaled up as load increases, and scaled down after load diminishes. This means that IP addressing of machines running microservices is constantly changing. So the challenge becomes: how do we route fixed traffic to a moving target?

In the past, a common pattern was to reference hosts using domain names rather than IP addresses. In this case, when a host IP changes, the DNS record is updated with the new IP address. Tools such as Consul can be employed to propagate DNS changes. Alternately, redundantly-deployed services can register with a load balancing appliance. The group of services is then referred to using the address of the load balancer. However, in a microservices architecture, this can rapidly become costly due to the large number of load balancers required.

To better solve this issue, we must get creative and route traffic in a more dynamic way. Service discovery is a pattern that lets us identify a group of microservices by name rather than by IP address. With service discovery, a centralized registry is used to store the locations of all services in the surrounding environment.

The most common pattern we implement is to have microservices push their own information to the registry on startup and say, “Hey, my name is service-a, and here is my IP address and port”. Another service can ask the registry for all IP addresses for services named “service-a”. The requesting service can then strategize which one of the services named “service-a” to talk to. This type of push-based discovery pattern can be implemented with Eureka (part of the NetflixOSS stack), and it requires discovery-enabled apps to use a client library to talk to the discovery service.

API Gateways performing reverse proxy operations can also take advantage of this service discovery feature, and can route all traffic for a specific path to a group of microservices of the same name. These gateways are utilized as a router of all inbound HTTP requests, which consolidates Internet-facing traffic under a single domain name. The router can also apply rules or filters to enforce security for edge services, for example, to require authentication. This gives you a fine degree of control over how different types of traffic are routed.

Exploring Alternate Designs

At Kenzan, we are always thinking of ways we can improve on our architectural patterns. Lately we have been exploring alternatives to the edge/middle microservice design pattern described in this post. The details of this alternate design will hopefully make an appearance in a future blog post, but in the meantime here’s a sneak peek.

We like to refer to this design as the one-edge/many-middle pattern. It might even become a three-tiered design as it evolves, with edge services, middle services, and data services. In this scenario, data services provide the data abstraction layer, middle services drive business logic, and edge services drive domain logic. The edge services have similarities to an API gateway, but they also make domain-specific decisions on which middle services to use. The result is a better decoupling of microservices and a clearer design with fewer edge services.

As we are learning, a particular microservice architecture may work for one organization but not for another. We will continue to explore different microservice designs, and evaluate the benefits and challenges of each.

Conclusion

To make microservices work for your business, it’s important to compose them correctly and place the right functionality in the right tier according to your chosen architecture. There are many ways to architect and develop microservices, and we are constantly talking about ways to improve the design.

When starting with a microservice architecture, plan a consistent strategy and define guidelines for the entire organization to use. Share best practices and lessons learned with the other teams, and continue to evolve microservice patterns. Consider the scaling capabilities, and build in capabilities like service discovery.

Going with microservices from the start can be a great approach. But what if you have an existing application you want to migrate to microservices? In our next post, we’ll talk about how to break up a monolith into manageable chunks.

Microservices for a Macro World

Tech Skills

Architecting for the Future At Kenzan, we often work with large, consumer-facing companies whose customers are demanding richer, more interactive, and friendlier experiences on all of their devices. As trends in software architecture evolve to adjust to these expectations, organizations need to create applications that are both highly available and highly scalable. We’ve been building…

Architecting for the Future

At Kenzan, we often work with large, consumer-facing companies whose customers are demanding richer, more interactive, and friendlier experiences on all of their devices. As trends in software architecture evolve to adjust to these expectations, organizations need to create applications that are both highly available and highly scalable.

We’ve been building web applications with microservices for a while now and have found they’re easy to manage, can be scaled independently or across servers, and offer flexibility to quickly deliver features.

In this blog series, we’ll look at how you can architect for the future using microservices, some of the challenges you may face along the way, and strategies for mitigating these challenges.

What Are Microservices?

Microservices have been around for a few years, but you may not have encountered them yet.

In a traditional architecture, all functionality resides in a single, monolithic server-side application. This makes it easier for one developer to understand the whole system or run it locally, but it can quickly lead to issues as the application grows in size.

In a microservices architecture, functionality is distributed across small, self-contained, modular services that communicate with one another over the network.

monolith-vs-microservices

What Are the Advantages?

Adopting a microservices architecture brings a lot of benefits – let’s check them out.

Up and Running Today

High availability and uptime are two big selling points for microservices. That’s because they allow for smaller components or services to be upgraded without risk of taking down an entire system.

Imagine a customer-facing application that has one monolith for all services, including account information, identity data, and login portals. Maintaining and deploying updates to just one of those services means you’re at risk of bringing down the entire application if there’s an issue. With microservices, if one service goes offline, the rest of the application doesn’t have to go down with it.

Scale to Meet the Future

The first thought that comes to mind when talking about scale is the amount of load a system can handle before falling down. But that’s not the only type of scale to consider when you’re building a microservice. When you’re dealing with big data, a microservices architecture lends itself to scale for velocity (number of active users on a given system) and for volume (how much data you have). With microservices, you can scale your applications just at the point of demand. You don’t have to scale everything together. For example, edge services that communicate directly with web clients often have higher load requirements than back end services, especially if caching strategies are used to reduce communication with the back end.

Microservices can also help scale your organization along with your application. Using microservices allows for distributing development teams more efficiently. Complex backend systems can be built faster by dividing workloads into multiple small teams, with each team responsible for a given set of microservices. Clear domain ownership means you always know which team to go to when there’s a problem with a microservice. Likewise, teams are empowered to operate and deploy independently at a delivery cadence that makes sense for them rather than coordinating large releases across many teams.

Every Service For Itself!

Let’s look at our imaginary monolithic application again. The many features of this application share resources like CPU, memory, network latency, and I/O, and as a result could easily overwhelm these resources, causing all the services to suffer. In a microservices architecture, many of these resources are isolated to the individual service and can be optimized more easily. Through containerization with frameworks like Docker, or serverless solutions like AWS Lambda and API Gateway, resource isolation is a much more cost-efficient practice in microservices. Services scale according to their own needs rather than to the needs of the busiest component.

Use of common protocols like HTTP, and standard interfaces like REST for communication with other services, allows microservices to be technology agnostic. Teams can choose to build microservices in the language they are most comfortable developing in. Having a microservice stack including both Node.js and Java applications is becoming more common. This lets organizations tap into a wider range of skillsets. (Choose technologies wisely, though, as some may not play nicely with other technologies in the microservice stack.)

What Are the Challenges?

Knowing why you should build a microservice is only half the battle. Knowing when to (or when not to) build one can be a trickier question. Every engagement is different, and there’s no one size fits all. Here are some of the key factors to consider:

  • Infrastructure – Adopting a microservice stack can require a bit of scaffolding to get up and running. Considerations such as infrastructure requirements, deployment strategies, monitoring, and configuration management come into play when building a custom microservices solution. Platform-as-a-Service products like Amazon’s Elastic Beanstalk can reduce the time required to develop a microservice platform, and they streamline the process of developers deploying code.
  • Code Compatibility – Microservices can suffer from code compatibility issues like monoliths can, but the single codebase nature of a monolith does allow code compatibility issues to be caught at compile time. In contrast, changing the interface of a microservice may go unnoticed until another microservice breaks after deployment. Maintaining API Contract Tests is a good way to ensure consistency of a microservice’s external API and avoid unintentional changes.
  • Shared Libraries – There will be many microservices doing similar things, and it often becomes apparent to put common patterns into libraries to be shared with other teams. Sharing code with other teams is like sharing open source code on GitHub. The code must be useful enough to share and intended to accept contributions from other teams.
  • Coding Practices – Many different teams working in siloed environments can result in vastly diverged coding practices. Whether or not this is an issue can be left to the discretion of the organization and their development culture, but establishing company-wide standards and periodic discussions of new patterns can help keep teams in sync.

Finally, microservices aren’t right for every application, like those with a limited scope, a small number of users, or a single data repository.

Conclusion

When applied to the right problems, microservices are a flexible solution that many companies are adopting to architect for the future. Given the complexities, you might decide to have an experienced guide on your journey.

In our next post, we’ll talk about how to put microservices to work to solve challenges now and prepare for future needs.


Have a question about building and implementing microservices at your company? Email us at info@kenzan.com


Darren Bathgate is a technical architect at Kenzan/ Over the course of his 5+ years at Kenzan, Darren has worked extensively with Java, MySQL, PHP, Cassandra, Node.js, oracle, Jenkins, Netflix OSS and Docker.

A Project Manager’s Guide to Time Management

Tech Culture

by Doug Melvin As a professional and consulting services firm within the ever shifting technology industry, Kenzan is trusted to consistently deliver high quality products and services. We take this expectation seriously and use the most progressive tools and approaches to ensure we meet those standards. Kenzan’s Project Management/Business Analyst (PM/BA) team is critical to…

by Doug Melvin

As a professional and consulting services firm within the ever shifting technology industry, Kenzan is trusted to consistently deliver high quality products and services. We take this expectation seriously and use the most progressive tools and approaches to ensure we meet those standards. Kenzan’s Project Management/Business Analyst (PM/BA) team is critical to our success as they support and guide the development teams through each project.

Working between multiple internal and client teams, our PM/BA’s plan, consult, organize, communicate and manage a vast amount of resources and information each day. To make sure projects are meeting deadlines and teams are communicating effectively, time management and prioritization are key.

Luckily, there are some techniques that can help keep the days running smoothly.

The Eisenhower Matrix
While navigating multiple projects, the Eisenhower Matrix  helps project manager organize their days while juggling unexpected tasks. Based on the criterion of importance and urgency, PM/BA’s sort their tasks and complete, delay or delegate  by categorizing them into one of the below four quadrants:

Time management means prioritizing your tasks
Source: http://www.businessinsider.com/dwight-eisenhower-nailed-a-major-insight-about-productivity-2014-4

The simple framework of the matrix allows for easy visualization without  complicated tools; a whiteboard or corkboard will do just fine. or those interested in a more portable method, Trello published a great blog post on how to use their tool to apply the Eisenhower matrix. If you’re familiar with Agile, an Information Radiator can also be used to visualize and sort tasks.
EisenhowerRegardless of how you draw the matrix, getting all the information out of your head and organized in one place makes decision-making less arduous and your work day more productive.

The Pomodoro Technique
Instead of racing to a deadline or fighting the lure of procrastination, the Pomodoro Technique is a simple time management system that breaks the work day into intervals with short breaks designed to eliminate burn-out and fight distractions.

Created in the late 1980’s by Francesco Cirillo, the approach divides each day into 25 minute work-periods — or Pomodoros — that are surrounded by short and long breaks. Short breaks are 5 minutes; long breaks are 25 minutes and are allowed only after four Pomodoros have been completed. Work should be done consistently through each Pomodoro and should stop only at break times. In a professional setting where email and IM’s are constant, it’s important not to use the break times for checking email. Instead, short breaks are good times to get up, get a glass of water or a snack. Long breaks are well spent getting some fresh air, getting lunch or just going out for a cup of coffee.

There are even some tools to help keep you on track. This Google Chrome extension blocks websites until it’s time for a break.

Time management with the Pomodoro Technique
The Pomodoro Technique was named after the Italian word for tomato. It’s creator, Francesco Cirillo, was inspired by his kitchen timer, shaped like a tomato.

For our project managers whose goal is ensuring development teams meet deadlines and complete deliverables, the Pomodoro Technique is  especially helpful for creating accurate project timelines by estimating the number of Pomodoros it will take to complete a task.

While these methods can work on their own, the true magic of the Pomodoro Technique and the Eisenhower Matrix become apparent when the two systems work in conjunction. Using the Eisenhower method for decision-making and the Pomodoro Technique for execution leads to  a more efficient and productive workday, while maintaining quality and consistency throughout every project.


Doug Melvin is a Senior Project Manager and Business Analyst for Kenzan based out of our Denver offices. When he isn’t working, he does his best to keep his puppy out of trouble and experiments with different programming languages. At Kenzan, Doug is responsible for ensuring that development teams deliver on time and on specification, with the resources they need, and assisting with the management of Kenzan’s Atlassian suite. His background in Computer Science originally brought him to Kenzan and has enabled him to support, and interact with, the highly technically-focused platform and development projects that Kenzan engages in.

Introduction to Pivotal’s Cloud Foundry

Uncategorized

Just a few weeks ago, ahead of their Spring One Conference, Pivotal launched the Partner Ready Program, designed to help businesses accelerate their digital transformation into the cloud. Kenzan is proud to have been named as an Advanced Partner in support of the Pivotal Cloud Foundry. As partners, some of our developers were given access…

Just a few weeks ago, ahead of their Spring One Conference, Pivotal launched the Partner Ready Program, designed to help businesses accelerate their digital transformation into the cloud. Kenzan is proud to have been named as an Advanced Partner in support of the Pivotal Cloud Foundry. As partners, some of our developers were given access to a deep well of knowledge around the cloud foundry as they work to understand all its capabilities.

Nicholas Eden-Walker, a Technical Architect based in our Rhode Island office was part of Pivotal’s partner immersion training where he learned what you can do with the enterprise-grade cloud foundry.

Lucky for us, he shared a little bit of what he learned in one of Kenzan’s weekly lunch & learns. We’re paying it forward by sharing his presentation below:

 

Confessions of a Tech Recruiter

Tech Culture, ,

By Isaac Lavoie We’ve all been there before. You’ve combed through job listings and found one that seems to be perfect. You submit your resume and land that first phone interview. After hanging up the phone you feel good about how it went, send a thank you note and wait, hoping for that elusive second…

By Isaac Lavoie

We’ve all been there before. You’ve combed through job listings and found one that seems to be perfect. You submit your resume and land that first phone interview. After hanging up the phone you feel good about how it went, send a thank you note and wait, hoping for that elusive second interview with the hiring manager. But it never comes. You meet the technical requirements, you have the education and experience, so what went wrong?

Being a talent acquisition coordinator (read, recruiter) for a technology company, I can tell you that it takes more than technical skills and a computer science degree to make it to the next round of interviews. It’s my job to not only make sure you fit the technical bill, but that you fit the cultural one too.

As tech companies shift to adopt more collaborative development methodologies and organizations restructure to foster more connected workplaces, it’s never been more important for hiring managers to ask the question, “Are you the kind of person we want at our company?”

This is often the first hurdle an applicant needs to clear in their interview process. The trouble is, no one ever asks the question out loud. Instead, a mix of technical traits and personality traits are used to arrive at the answer. Where many applicants fall short is understanding how best to present their non-technical assets in our deeply technical field.

While the mix of technical and personality traits may shift for any given opening, some of the easiest ones to bring to an interview don’t take any training at all.  Ask yourself these questions as the answers can easily influence the hiring manager’s decision to move someone forward in the interview process.

Do you have the Drive? This is the precursor to all that follows. How have you been guiding your own career? Can you answer the questions: Why do you do this work? How do you hope to grow? You should have the answers — not only for the interview, but for every day interactions and career planning.

Do you have Initiative? You’re an active participant in our communities such as GitHub, meetups, and specialized user groups. Show the employer that you have a passion, that you are curious, hungry for more and eager to expand your skills.

Do you have Enthusiasm?  This is shown not only through your presence when interviewing, but also in your work history and community engagement . You never know which conversation will lead to a job offer, so bring your A-Game to everything you do.

Are you Honest? If your resume reads 4 years in Apache Spark (insert new hot tech here) and it’s only been around since 2014, you definitely will not be getting an interview. If your code is pulled from someone else’s public github… well you know.

Are you OpenShow openness to criticism and new ideas. Embracing other ways of solving problems or challenges is a key indicator for how you work with others. No (wo)man is an island, and, no one wants to work with someone who is right all the time. Exchanging ideas is how we learn and get better. 

Are you Humble? Too much boasting about a success or making excuses about a failure can turn off a recruiter quickly. Being humble shows that you can learn and help others to learn. In this case, humble pie really does taste good.

Do you have a solid foundation? No AngularJS without solid Javascript, friends. With a plethora of bootcamps, online trainings and more out there, the pressure to list hot tech on your application is on. But beware, it’s easy to poke holes in someone’s facade (testing, code samples, anyone?)

You don’t even have to have a technical degree to prove you have a solid base. Hiring managers know that there are many valuable routes into technical work: school, work experience and natural curiosity all matter. As a job seeker you should display a mastery of core concepts before you highlight the technology du jour.

With the tech industry booming and more and more jobs opening everyday, you need to show that you are  not only the right technical solution for a company, but also the kind of person a company wants to be part of its team.

So why not turn this all on its head? Next time you’re in an interview, ask the company what it thinks about community or team work? This is a conversation that tech recruiters want to have. Perhaps if you bring your A-Game, they will have to bring theirs as well.


Isaac Lavoie is the Talent Acquisition Coordinator for Kenzan and is based out of our Rhode Island offices. Though most of his time is spent riding around on his bicycle, he is also responsible for supporting the Kenzan HR team and for bringing new Kenzanites on board. With a background in the environmental education, mechanics, and group consensus building, Isaac is well suited to introduce applicants to the dynamic organization we call home.

Redesigning the Tech Hiring Landscape

Tech Culture

By Kevin McKenna As huge advances in technology continue to push the boundaries of our digital experiences, companies across industries are looking for highly skilled employees to help them build the tools, products and services that power our lives. As a result, the demand for top talent is quickly outpacing the supply. The consensus in…

By Kevin McKenna

As huge advances in technology continue to push the boundaries of our digital experiences, companies across industries are looking for highly skilled employees to help them build the tools, products and services that power our lives. As a result, the demand for top talent is quickly outpacing the supply. The consensus in the technology sector is that we are in a talent drought. By 2020, the U.S. Department of Labor expects that there will be more than 1 million unfilled IT jobs as the demand for highly-skilled employees will far exceed the supply of computer science graduates.

At Kenzan, where we’ve hired 40 people over the last year, we believe that there is a vast pool of untapped talent that is ready to work, but often overlooked. These candidates have the skills and motivation to perform these jobs, but lack the one thing that will get them an interview: a four year computer science (or similar) degree from a college or university. Instead, these potential employees have acquired their skills through non-traditional means like industry-certified training programs, independent projects, coding boot camps, apprenticeships and high-quality online courses.

IMG_6553 (1)Last week in our Rhode Island office, we hosted High Tech Recruiting: Cultivating the Unconventional, an event aimed at exploring and expanding the tech hiring landscape in lil’ Rhody. Along with our co-host TechHireRIthe event brought together work-ready talent with employers and community partners. The goal here is to close the opportunity gap for many of these job seekers and to encourage hiring companies to look outside of traditional recruiting sources.  

Speaking to a packed room, Stefan Pryor, Rhode Island’s Secretary of Commerce, talked about the state’s initiatives to support these efforts in order to spur hiring and job growth. He also spoke to Rhode Island’s commitment to be the first state to bring a computer science curriculum to all schools, K-12.

IMG_6555 (1)
RI Commerce Secretary addresses job seekers, employers and tech trainers on Aug. 25th in Kenzan’s office.

Attendees also heard from organizations that are training, educating and developing these tech workers so that they enter the workforce with the same skills and competency as their degree-holding counterparts. LaunchCode, YearUp, General Assembly, Apprenticeship RI, TechForce and Computer Science Minors each led a discussion about the future of IT training, with both employers looking to recruit and candidates looking for a job.

The event sparked a conversation that will carry over into community partnerships as all of us — employers, job seekers, tech training services, industry leaders and government officials — work together to give those who have the skills the same chance to get the job.

Kevin McKenna is the Director of Operations for Kenzan and is based out of our Rhode Island offices. Though most of his time is spent running around with his dog, he is also responsible for supporting current Kenzan teams and for bringing new Kenzanites on board. With a background in the building trades and working with small teams on ambitious projects, Kevin is well suited to assist in providing a solid foundation for a dynamic organization.

Combining AWS Services to Analyze Data

Tech Skills

As we enter a new era in the Internet of Things, millions of devices are sending out streams of data. Analyzing this data can be a huge undertaking, but by combining AWS services, one can create a scalable dashboard.  We hosted another Lunch and Learn a few weeks ago, where Nicholas Sledgianowski and Charles Palczak…

As we enter a new era in the Internet of Things, millions of devices are sending out streams of data. Analyzing this data can be a huge undertaking, but by combining AWS services, one can create a scalable dashboard. 

We hosted another Lunch and Learn a few weeks ago, where Nicholas Sledgianowski and Charles Palczak gave an overview and demo, which you can find below. 

In order to create innovative, scalable and intelligent solutions for our clients, Kenzan believes that continued development is crucial. Learning from fellow Kenzanites is just way that our employees gain new skills, so each week we host a lunch and learn, for employees across all four of our offices to join in. 

Stay tuned for more videos from our Lunch & Learns.

The Code to Collaboration

Tech Culture

By Ming-Lien Linsley By 2020, it’s estimated that 20.5 billion things will be connected to the internet, making every day things like driving a car or going to the doctor, a digital experience. With each new advancement in technology, it’s easy to forget that the most valuable connections in our lives are the ones we…

By Ming-Lien Linsley

By 2020, it’s estimated that 20.5 billion things will be connected to the internet, making every day things like driving a car or going to the doctor, a digital experience. With each new advancement in technology, it’s easy to forget that the most valuable connections in our lives are the ones we have with other people and it’s those relationships that are the building blocks for everything from the cities we live in to the technology that drives our digital lives.

At Kenzan, those connections are the foundation of the work we do, as each project’s success is attributed not to individuals, but to the collaborative effort of Kenzan and partner teams working together, guided by a spirit of open communication, excellence and kindness.  These values have enabled longstanding, productive relationships between our partners and Kenzan, by way of open dialogue and collaboration among key stakeholders.

Looking beyond Kenzan, the tech sector is trying to break down the traditional silos that exist between teams in an effort to create more efficient environments where building, testing and releasing software can happen more frequently, rapidly and reliably. Methodologies in the software development cycle have shifted to embrace practices like DevOps and transform IT culture into one where communication and collaboration are the guiding principles of innovation and growth.

Print

However, the formula for creating an environment where effective teamwork flourishes isn’t as simple as knocking down cubicle walls and opening up office spaces. Instead, collaboration should be thought of as a goal, never a given, supported by a company’s culture and values. For organizations that are exploring a transition to DevOps practices, the first step is understanding that the most crucial change is not in tools and technology, but in the way employees work together.

Over the last 12 years, as Kenzan has grown from a small band of contractors to more than 150 employees across 4 offices, we’ve worked hard to maintain our culture of collaboration and learned a lot along the way. Some of our keys to collaborative and successful relationships include:

Listen First.
The groundwork to success is laid from the very first conversation where a common understanding of the scope and goals of a project is established. In order to ensure no team member is working in a silo, they first need to know the why of a project, before they can work on the how, so we host an all-hands kickoff meeting for everyone from the architect responsible for the first deliverable to the final Dev Test engineer so they can ask questions or raise concerns.

Plan, then take action.
It’s easy for a solo developer to jump into a project only concerned with his or her piece and failing to see where they fall in the bigger picture. By laying out a blueprint for the full development cycle, each team member sees how they fit in the grand plan and how they can provide a strategic solution, not just a service or a piece of code.

Establish a common language.
Oftentimes, architects, developers, testers, operations and other participants speak different professional languages and operate as separate entities, which leads to inconsistencies and confusion in the way a company’s products, services, technologies and even mission are talked about both internally, and to greater extent, externally. In order to keep things consistent at Kenzan, we created an all-company guide that highlights the who, what, and why of the company to make sure everyone is delivering the same message and working towards the same goal.

Invest in tools for collaboration.
As workplaces become more distributed and more employees work remotely, it’s important to make sure that they are empowered to do their best work wherever they are.
PrintThere are a slew of tools that facilitate chat, collaborative writing, video conferencing, ticketing systems, continuous integration and continuous delivery, that make it easy for employees to quickly get feedback, bounce ideas off each other, solve problems, track progress and share documents.  Examples of the tools we use include JIRA, Hipchat, Confluence, and BlueJeans.

But value in-person time.
Success in business is due in large part to building relationships. Despite the many advancements in the quality and variety of digital tools, there is still nothing like a face-to-face meeting. In fact, a study from UCLA found that up to 93% of communication effectiveness is determined by nonverbal cues, something you won’t get from digital communication. As a professional services firm, solid relationships with our clients are a crucial element to project success. Relationships start during the discovery phase when team members not only get to know the scope of a project, but also each other. During this time, a conversation over a conference line just doesn’t do the trick, so we send our teams onsite with clients or to our other offices to work hand-in-hand.

Establish trust.
The cornerstone of every successful collaboration is trust, which is established when teams embrace accountability, transparency, reliability and support as core principles. When these principles are embraced, everyone works together and no one person is responsible for success (or failure). Without them, all the tools, meetings and planning in the world will do nothing to improve collaboration.

Empower the team.
Micromanagement can be a poison to collaboration and is often an indicator that there is a lack of trust between employees and leadership. Giving employees autonomy means they aren’t burdened by bureaucracy, can freely approach management when they need help, and will be more open to feedback.

Encourage employee connection.
Leaders who are looking to increase collaboration among their employees should focus upon how the company’s culture fosters connections between people. By creating a work environment where relationships flourish, an environment that promotes trust, yields open feedback, and inspires innovation will emerge.  Whether it’s small changes around the office like a communal kitchen or bigger investments like sponsored company outings, encouraging positive employee relationships can mean big improvements in the way they work together.

The bottom line is that it doesn’t take a massive monetary investment to make small and meaningful changes that improve the way employees engage with each other. When employees feel connected to the company and their colleagues, no challenge is too big.

Ming Linsley is Kenzan’s EVP of program management and client solutions, based out of our Denver office. She works with teams across the organization, from our project managers and business analysts, to our engineers and architects. With over a decade and a half of experience in advertising, online marketing and client solutions, Ming ensures our client relationships are strong and growing.