As more and more business are going digital, the question many companies are asking themselves isn’t how they’ll make this transformation, but who will help them do it. That question is becoming increasingly more difficult to answer. While technology is evolving with lightening speed, the demand for highly-skilled employees who will support this work is…

As more and more business are going digital, the question many companies are asking themselves isn’t how they’ll make this transformation, but who will help them do it.

That question is becoming increasingly more difficult to answer. While technology is evolving with lightening speed, the demand for highly-skilled employees who will support this work is far outpacing the supply.

Kenzan and General Assembly are bringing together Denver-area technology companies and educational resources to address the tech skills gap in Colorado. On January 19, at Kenzan’s office in downtown Denver, we’ll discuss actionable solutions to the challenges both job seekers and hiring companies are facing. Our panel of industry experts from Galvanize, Skillful, Istonish and GoSpotCheck will talk about:

The challenges tech companies face when looking for tech talent;

Why you shouldn’t disregard a candidate that doesn’t have a degree in computer science;

In-demand skills and where you can find employees that have them;

How tech companies and educational organizations can work together to grow the talent pipeline;

Supporting tech workers through continued learning and development programs

Rona is a Director of Engineering for Kenzan where she leads technical teams in the production of web applications. She is active in the hiring of development resources and helps drive initiatives that encourage the growth of Kenzan’s employees.

From the cloud, to the Internet of Things, to big data, companies are embracing digital transformation to help them quickly react to marketplace shifts, consumer demands and new opportunities. The roadmap for digital transformation is different for all companies and often calls for customized software, which can be a significant investment of time, money, attention…

From the cloud, to the Internet of Things, to big data, companies are embracing digital transformation to help them quickly react to marketplace shifts, consumer demands and new opportunities. The roadmap for digital transformation is different for all companies and often calls for customized software, which can be a significant investment of time, money, attention and resources.

Software development can sometimes be seen as a slow and expensive process, especially at the enterprise level. Managing these factors are fundamental priorities and few people are better equipped to keep things under control than project managers.

Many organizations that are on a path towards digital transformation don’t fully recognize the value PM’s add to software development teams. According to a 2016 report from the Project Management Institute titled “The High Cost of Low Performance”, less than two in five companies surveyed place a high priority on creating cultures that recognize the importance of project management as a driver of better project performance.

But for those who might disagree, we’re here to dispel some myths about Project Managers:

Myth: Project managers are clueless.

Busted: Technical comprehension is as critical to the success of a project as leadership and strategic business management. While a PM doesn’t write code, they spend their days working with those that do. In order for a PM to adapt quickly to changing conditions, assign and re-prioritize tasks, communicate effectively and spot risks, they need an understanding of relevant tools and technologies that the team uses.

Myth: Project Managers just schedule meetings and manage calendars.

Busted: Project managers guide the structure, scope, quality and budget of a project while also representing the interests of the product owner. The real value of a project manager is as a leader, liaison and mentor. With a big picture point of view, the project manager balances and guides software development teams while defining requirements and goals to ensure the teams meet expectations — on time and on budget.

Myth: Project managers are just paper pushers.

Busted: Project managers define policies and procedures that enable success. Without the structure of process, a project can easily fall apart. A project manager knows the operational requirements (things like time sheets, budgets and resource allocation) and can navigate communication channels with clients so technical team members can focus on what they do best – developing software.

Myth: A Project manager’s top priority is execution.

Busted: Project managers support the team from start to finish. While the software delivery lifecycle (SDLC) is the guiding framework for development, it doesn’t stand alone in supporting and achieving business objectives. Project management methodologies work in tandem with the SDLC for the initiating, planning, monitoring and delivery of projects, which provides consistency and stability of process through every phase of the SDLC.

Now that we’ve dispelled some of these major misconceptions about project managers, it’s (hopefully) clear how important they really are. Think about all the projects you or your organization have worked on that went over budget, missed a deadline or derailed entirely. It may be too late to go back and right those wrongs, but it’s not too late to consider how future projects — and your company as whole — will benefit from the guidance of project managers.

For companies that are looking to get or stay competitive, strong project management practices can play a crucial role in driving the business forward through digital transformation. Contact info@kenzan.com to learn more about our project management and other services.

As a certified Scrum Master in Agile methodologies, Jennifer Aczualdez leads Kenzan’s project management and business analysis team . She manages the scope, budget and timelines of projects and acts as a central point of contact for both internal and client teams. She is involved in the full software delivery cycle, from initiation and planning to monitoring, delivering and closing.

Kenzan has created many microservice applications over the years, with many of those running thousands of instances. Our experience is that a lot of organizations want to take advantage of the increased scalability and other benefits that microservices offer, only they don’t know where to start. How do they set up data? How will microservices…

Kenzan has created many microservice applications over the years, with many of those running thousands of instances. Our experience is that a lot of organizations want to take advantage of the increased scalability and other benefits that microservices offer, only they don’t know where to start. How do they set up data? How will microservices affect their deployments? What technologies should they use? The task can feel quite daunting! The reality is that it’s much simpler than it seems. To prove this point, Kenzan created an open source microservices project called Million Song Library (MSL).

Not familiar with the benefits of microservices yet? No problem! Check out our blog series on microservices for a deeper dive. In a nutshell, microservices are a set of small services that make up a full application stack. The services are typically broken down by functional area within the business. This brings several core benefits:

So what is Million Song Library? At a basic level, MSL is a microservices-based application that lets users navigate through large sets of music (albums, artists, and songs) while also tracking and rating their favorites. That said, the functionality of the application is actually secondary to the main goal: to show how easy it can be to create microservices and run them both locally and up in the cloud. As you’ll see, with the help of good, solid architectural patterns, it is simple to create and maintain a fully functioning microservices application.

Over the next couple of weeks, you can look forward to a series of blog posts covering the different aspects of MSL. At the end of the series, our hope is that you’ll have a good familiarity with microservices, the technologies used in MSL, and its core architectural patterns. You’ll also be able to run MSL locally as well as within your own AWS environment.

At this point you probably want to know more about the architecture of MSL and what makes it tick. So let’s get to it!

For MSL, it’s best to review the stack from a bottom up approach. The data layer leverages Cassandra NoSQL data stores, and there is a separate data collection client for each functional area. The services are also broken up into functional areas, each one related to managing a library with a million songs. These include things like catalog services, login services, and even ranking services. Each of these services are fully RESTful, and each (ideally) has a very small set of responsibilities. The task of managing access to these services belongs to a proxy layer (Zuul) that handles all the API traffic coming into the application as well as discovery of the correct microservice.

As it stands now, MSL is easily deployed into AWS, but it was intentionally built to be deployed into other environments. Want to drop the routing layer logic, the services layer, and the data tier into another cloud or data center environment? You can do that!

From a front-end perspective, MSL is comprised of a few core technologies. Our goal was to use a technology stack that we find easy to work with and is something common in the marketplace:

AngularJS 1.4 – Front end framework

ES6 – JavaScript environment

Less – CSS preprocessing

Gulp – Build management

NPM – Front end package manager

Webpack – Bundler for modules and dependencies

Karma – Test runner for JavaScript

ESlint – Style guide linter tool

Material Design – Standard design toolkit

The back-end technology was architected with the same simplicity in mind. Given the robustness of the Netflix OSS stack, we decided to stick with Java and gain the benefits of a solid Netflix OSS ecosystem:

This all probably seems like a lot, but don’t worry! By the end of this blog series, you will be familiar with all these technologies, along with the recommended architectural patterns to use for the microservices. We are excited to release MSL into the open source community and watch it take flight. And, we’re glad you came along on the adventure!

Craig Martin is the Vice President of Engineering at Kenzan. He is based out of Denver, and oversees all engineering activities within Kenzan. Many of his current responsibilities have been focused on architecting, and leading projects to create, highly scalable cloud-based microservice applications.

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.

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.

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 ScopeBefore 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 ArchitectureThis 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 ArchitectureWith 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.

TestingWe 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 ProductAfter 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.

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…

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.

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.

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.

What Are the Advantages?

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.

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 MatrixWhile 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:

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.Regardless 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 TechniqueInstead 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.

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.

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:

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…

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 Open? Show 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.