Category: Development

Building Distributed Applications

10 Nov, 19

18 Jan, 21

Software Development – Insourcing Vs. Outsourcing

Sandeep Raheja

January 18, 2021

development, hot_picks, insights

Perhaps the central issue when beginning a software development project is deciding to insource or to outsource. This decision factors in questions of cost, time, and quality of work. It is often the difference between a successful project and a waste of time and resources.

Insourcing is what is traditionally known as in-house recruitment. When a company decides to insource their software development, it requires that they hire a team of employees to build their project. With this approach, the company directly manages the team of developers, rather than it being a third-party organization.

Outsourcing, on the other hand, is when a company uses an outside software firm to develop its project. In recent years, we’ve seen more and more companies choose to outsource their development projects in an attempt to cut down on in-house numbers and save time and money. According to Stratistics MRC, the global IT outsourcing market is expected to reach $481.37 billion by 2022. It’s a big business.

So how do you choose? Below, we compare issues of cost, time, and quality for insourcing and outsourcing. We also discuss the common pitfalls associated with choosing the wrong software development option. To expand on this, we consider use cases of both options, offering a better understanding of both development approaches. Finally, we break down the decision-making process of choosing between insourcing and outsourcing, as well as consider a hybrid option. By the end, you will be fully equipped to make the best decision for your software development project.

Primary Considerations of Insourcing vs. Outsourcing

When deciding to insource or to outsource, there are a few primary issues to consider. Namely, how much will it cost, how much time will it take, and what quality of work will be provided. These considerations will likely be the deciding factors when choosing a development approach.

Cost

At the end of the day, you’re only able to do what your budget allows. As such, the cost of software development will determine how you approach your project.

Because insourcing requires that you hire employees, you will have to pay them accordingly. This means a gross salary, benefits, pension contributions, and taxes. You will also have to consider the expense of office space and equipment, as well as additional IT costs. Additionally, there may be recruiting and training costs for new employees.

When you outsource your development project, you and the contracted team will agree on a fixed hourly or team rate for the duration of the contract. The firm or individuals that you work with will be responsible for the office space, software, and other financial requirements needed for the project. They also handle all of the recruitment and training costs necessary to build out a successful development team.

Bottom Line

The question of which will be the more cost-efficient option is typically dependent on the timeline of the project. If it will be an on-going project that will take years to build and maintain, it could be cheaper to take on all of the costs associated with insourcing. If it’s a short-term project that is mostly a one-and-done deal, then it will likely be cheaper to outsource the work.

Time

Insourcing tends to be a time-consuming process. When you decide to hire a new team of employees, you have to market the positions, interview applicants, decide on team members, get them acclimated to the office, and train them for the work you need to be completed. After all of that, you can finally begin the project.

All in all, the insourcing process can take months. What’s more, recruiting software developers is quite competitive. It’s difficult to find experienced and talented developers who are available within your local market. Recruiting high-quality developers often demands competitive wages and limits you geographically.

Outsourcing software development grants you access to the global market. Because geography is no longer an issue, outsourcing allows you to tap into talent from anywhere in the world. As a result, you have exponentially more options when it comes to available development teams. And because you don’t have to assemble and train the team yourself, all you have to do is find a team that fits your needs and can work with your budget. In the end, it can take as little as two weeks to begin your project.

Bottom Line

The added time associated with insourcing can be worth it for long-term projects. Investing the extra time to create your internal team can be beneficial if your project demands years of work. For shorter projects, however, it just doesn’t make sense to waste so much time starting your project. Outsourcing is your friend when it comes to short-term software development.

Quality

The last thing you want is to put time and money into a project just for it to leave you wanting more. Unfortunately, the question of quality of work with insourcing vs. outsourcing isn’t as cut and dry as the issues of cost and time.

With insourcing, the quality of work you receive will be entirely dependent on the team you assemble. Because you’re more limited on the developers you’ll be able to recruit, you may not have access to the same levels of talent and experience that you would have with outsourcing.

On the other hand, insourcing gives you more control over your team of developers. This makes it less likely that you’ll run into unexpected problems once the work is delivered. And if issues do arise, they can be addressed immediately. You’re able to groom your team to meet the needs of your project as they evolve

Because outsourcing grants you access to more developers with diverse abilities, there is a greater chance that you will be able to find niche developers with experience doing the work that your project demands. With developers who already have the knowledge and training that your project needs, there isn’t as much of a need for grooming and direction. Outside teams are often elastic and capable of expanding in short bursts when additional skills or expertise is required. With a good development team, outsourcing can produce quality work with few hiccups.

Bottom Line

At the end of the day, the quality of your software depends on the quality of the team building it. If you’re able to hire a team of developers who have the skills that your project requires, insourcing will likely produce higher quality work. The advanced collaboration that is facilitated by insourcing software development just can’t be beaten. If your project demands more niche developers, however, outsourcing could be the better option because it grants you access to a wider range of experienced developers.

Common Pitfalls

The biggest problem associated with choosing the wrong software development approach is typically the result of companies inaccurately assessing the needs of their project. We’ll elaborate on the decision-making process below, but you’ve probably been able to conclude that insourcing is better for long-term projects and outsourcing works best for short-term projects. When a company believes their project will need months or years of building and maintenance, but it only needs a month or two of work, they will likely find that they’ve wasted time, money, and resources insourcing their team of developers.

More issues arise when companies try to force their project through, even though their development team — insourced or outsourced — lacks the knowledge necessary to complete the project. All too often, companies are eager to get started, so they just hold out hope that whatever skills the team lacks will resolve themselves in the end. Unfortunately, this doesn’t usually work out. Companies are then forced to either hire more team members or send the project to be completed by yet another third-party development firm.

What it comes down to is assessing your needs and taking the time to find a team of developers that has the skill and training to complete your project. Trends in software development move quickly, so it’s understandable to want to start as quickly as possible. Nevertheless, rushing into a project will almost always take more time in the end. It’s better to invest more time in the beginning to find or assemble a team that will be able to meet your needs than to pay for it later when your project cannot be completed.

Use Cases of Insourcing

As we’ve discussed, insourcing works best for long-term projects. But how do you know whether or not your project is long-term? Well typically, long-term projects are ones that will require consistent updates and changes to maintain. These are ongoing projects that take three or more years of work and building.

Long-term projects are usually strategic or aimed at providing services. Strategic software development projects affect a company’s organizational structure and offer qualitative results — think coverage, integration, and image. Software projects that result in usable services tend to be user-defined. These can be quantitative — create value for the company — or qualitative — increase the quality of the services provided by the company.

Insourcing can also be a good option if the project does not require niche skills. Because onboarding development employees limits you geographically, you may not be able to find developers with the niche skills required for more unique projects. If you’re building a big project, but one that is relatively run of the mill, insourcing can be a successful development approach.

Use Cases of Outsourcing

Outsourcing works best for short- and mid-term projects. Short-term projects are ones that can be completed in less than a year, and mid-term projects are ones that can be completed in one to three years. Projects like these are generally smaller in scope and are aimed at offering quantitative benefits for the company — think cost, schedule, and performance.

Alternatively, outsourcing can be a successful option for unique projects, regardless of the timeline. If your project demands niche skills and training, outsourcing can be the easiest way to find developers that know how to build it.

How to Decide Between Insourcing vs. Outsourcing?

Deciding to insource or to outsource comes down to assessing your needs. You must first layout all of the necessary components required to complete your project. These include:

An end-product conception
How much the project will cost
The timeline of the project
The software needed for the project
The hardware needed for the project
The number of developers required to complete the project

Once you have a developed understanding of the needs of your project, you can then determine your development approach. If your project has a long-term timeline and is relatively common, insourcing could be a successful development option. If your project is short-term or requires a niche skill-set, outsourcing is likely your best development option.

A Hybrid Solution

A scenario that we have yet to consider is the hybrid solution. Sometimes, the worlds of insourcing and outsourcing fuse together to make a development project work. It’s a little unconventional, but sometimes that’s what it takes to get a project up and running.

Say your insourced team has been working great. They’ve made lots of progress and you can see your idea coming to life. But then they hit a snag in the thread. All of a sudden, progress stops and the project comes to a halt. In this case, outsourcing a portion of your project might just be the thing that gets your project moving again. Typically, software development firms are more than happy to work on part of your project, just to get you from point A to point B, and then hand it back off to your team of insourced developers.

As we said, the hybrid solution is a little less common, but it can be a successful way of developing a software project. There’s no reason to limit yourself — or your project — to the false dichotomy of insourcing vs. outsourcing. Why not have both?

Conclusion

Hopefully, we have provided you with a better grasp of the question of insourcing vs. outsourcing. With a fleshed-out plan and an understanding of your needs, you should now be able to make an informed decision when choosing to insource or to outsource your software development project. And don’t forget — a hybrid solution could be the approach that works best for your project.

15 Nov, 19

13 Ways To Keep Innovation Alive Within Your Team

25 Sep, 19

How to Ensure Cross Team Coordination to Complete Projects on Time?

12 Feb, 18

3 Principles for Reducing Development Costs Without Compromising Speed or Quality

Naveen Joshi

October 20, 2020

Marc Andreessen’s observation that “Software Is Eating the World” is as true today as it was when he published his famous Wall Street Journal essay nearly a decade ago. The idea that “every company needs to become a software company” is not a trivial undertaking regardless of their industry, age, or size.

The pressure to make high-quality software in less time is not new, nor is the pressure to do more with less. And the perceived tradeoffs between cost, quality, and speed seem impossible. Here are three principles we use with clients when building software on-target, on-budget, and on-schedule.

Relationships Before Requirements

If speed matters, then it’s worth remembering, as Steven Covey says, that “business moves at the speed of trust.” We believe that’s also true for software development. Trust always affects two measurable outcomes: speed and cost. Levels of trust are based on the quality of relationships. Strong relationships increase trust. Trust increases speed. How? Through closer collaboration and rapid feedback.

Close collaboration built on trust fosters the exchange of ideas. Mistakes aren’t hidden. Barriers are quickly identified. Silly or not-so-silly questions are safe to ask. Developers and stakeholders can talk directly rather than playing the telephone game through layers of management.

Productive relationships lead to rapid and frequent feedback. The easiest way to avoid rework, getting off-target, or catching errors is by rapid, frequent feedback. Challenges are inevitable when developing software. However, when relationships are strong when trust is present, and when communication is open, small issues are quickly spotted and addressed they can fester.

Design before Development

Humans are visual beings, and we like to see things to understand them. Design thinking and design practices make abstract ideas and concepts concrete and visible. Napkins and dry erase markers are faster, cheaper tools for getting clear than jumping straight into code. Skipping design and going straight from concept to code. We use design to get clear on two critical factors: business value and user goals.

Functioning software isn’t enough, even if it’s pretty. It should improve business by increasing revenue, decreasing development costs, or reducing risk. We first want to understand how the software will increase productivity, save time, simplify operations, create competitive advantages, or ensure compliance.

Equally important is understanding user goals. A bad user experience is bad for the business. Software that doesn’t create business value or isn’t used by people is a primary cause of waste. It’s easy for time and money to slip away when project leaders and developers are operating in a grey area. The best tool here is your eyes and ears. Observe people in action. Listen, ask good questions, and listen to some more. Curiosity and empathy are more important than knowledge at this stage.

Before the first line of code is written, we first get clear what needs to be done and who it needs to be done for. Sketch it out. Map it out. Talk it out. Create wireframes. Create a prototype. Then it’s time to code.

Adapt to Change Over Following a Plan

Dwight Eisenhower said, “planning is everything, the plan is nothing.” We strongly believe in planning. Why? So that we can effectively adapt to the rapidly increasing rate of change. Market conditions and solution options are never static. Customer expectations are rapidly evolving. Through planning, we break work down into smaller parts of value so we can develop, test, and deliver them every two weeks. These rapid cycles of development and testing help catch issues early, when they are easier and less expensive to correct. Problems caught today cost less to fix – and are more quickly remedied – than problems caught tomorrow.

We expect change, and even welcome it. Working in shorter cycles allows you to produce incremental yet meaningful and verifiable units of value. Each day’s work is reviewed and micro-planned. And every two weeks we show verifiable work progress. Frequent testing allows developers to keep projects pointed toward dynamic and ever-evolving goals.

25 Sep, 19

22 Nov, 19

How Much Does Software Development Cost?

1 Sep, 20

Naveen Joshi

September 1, 2020

Understanding how much it will cost to develop a new software can be a confusing thing. Budgeting and pricing software projects depends on understanding the cost of software development, and there are a number of factors to consider when pricing a project.

Expectations

Managing expectations and communicating clearly is key when it comes to pricing a project and predicting just where your money will go as your software is developed. If you go into a project with a vague idea of what you are looking for, you will probably spend a lot of time and money without any concrete results.

To accurately estimate the cost of a project, you have to fully understand the problem you are trying to solve and have a clear vision of how the software will help find the solution. Having a grasp on, formulas, workflows, and other core architectural issues at the start of a project will help you project costs, find places for saving money and avoid going over budget. Discuss pricing with your developer, prioritize a list of must-have and could-live-without features, and work with your team to understand where your money is going and what road bumps could lead to spending more as the project progresses. There are many technologies available and understanding at is right for your project will eliminate extraneous costs and guessing games. There are unscrupulous developers out there who would like to build you a java applet when a few lines of JavaScript would do, and if you don’t understand the difference between the two, it is likely you will pay more than you need to for development.

An unfortunate reality in software development is also the “ask a barber if you need a haircut” phenomenon. Every developer has their favorite tools, databases, and they like to use them. When you ask a developer for advice on what tools to use, they often respond with their favorite, which are not necessarily the correct or most cost-effective ones for your project. When you are aware of the different technologies available, and make the choice yourself what to use rather than letting the developer decide, you have a much higher probability of a swift and budget-friendly outcome. If it helps, ask your developer to recommend multiple tools for your project and research which of those will meet your needs at a low cost, and which are worth splurging on for the long-term success of your development.

At the end of the day, knowledge is power, and the more information and understanding you have about your project, the better it will turn out and the closer to on-budget it will be.

Types of Project and Costs

There are different types of software development work agreements, each of which is appropriate for different situations.

Fixed-price contracts typically have an agreed-upon price and pre-determined milestones. These are beneficial because the developer absorbs the risk of time delays and unknown issues regarding how long your development will take. If there ends up being more work than expected, or the developer isn’t certain how long it will take to do something, this is a good choice.

The cost of fixed-price software development work can range from a few dollars on sites like Upwork, to millions of dollars. Generally, the more money that becomes involved, the stricter the contract, and more concrete the deadlines. It is often possible to get very good value for your money with fixed-price contracts.

Fixed-price projects are also the most complicated way to hire. It can be difficult to regulate the hours worked on a project. If a developer is motivated and everything goes well, it can turn out nicely but it is also possible that the developer has other, better-paying, or hourly work that will be prioritized. Because you are not getting a timesheet or invoice, it is very difficult to make any demands or control the number of hours worked. Another thing to keep in mind is that a fixed price job gone wrong can put a developer in financial trouble. If the amount of work is vastly more than expected, while you think you are getting a good deal, the developer is actually becoming financially unstable and could either face bankruptcy or just disappear. This can leave you with a half-finished project and no developer. So, while initially driving a hard bargain for a fixed price job with a developer seems like good business, it can backfire.

Hourly contracts are the most common type of contract work used for software development. Hiring someone hourly sets upfront expectations about not only the price of the work but the number of hours they can commit to the project.

It is also easy to get an estimate of how much per hour a specific software development task will cost. You can get quotes from multiple developers without committing to hiring someone.

In general, as with so many other things, you get what you pay for. Lowball offers from offshore developers may seem tempting, but developers who can command higher rates are charging higher rates.

By choosing to pay hourly, it is easy to understand how many hours are being worked on your project and make demands regarding the pace of the work. If you have a concrete deadline and you need to be sure the work is done by a certain date, an hourly contract will help make sure that the hours needed to finish the project are being worked.

Disadvantages of hourly contracts are usually felt when things take longer than expected. If the project ends up taking a lot longer than anticipated, or there are scope changes, the project can get more expensive than originally budgeted.

If you believe your project will require full-time work from one or several developers, hiring someone could be the best solution. With a new hire, you negotiate salary and other benefits up front, and both parties are obligated to stick to that agreement.

Obviously, a hire of one or more people will only be possible for the more well–funded employers but a long term project that requires 40 or more hours of work per week will often be best suited to full-time employees. You could certainly pay a contractor or an agency for a full-time commitment, but having someone on your payroll has a number of advantages in terms of being able to control the project.

Doing it yourself. While this solution may not be for everyone, doing it yourself is the way to go for some development projects. If you develop your own software, the only cost is time and development overhead.

As more and more people learn to code, it is common that small projects are done in house. Before you hire someone to do software development for you, it might be worth considering if this is a task you can manage yourself with a bit of learning.

Other Costs

There can be other costs besides labor to consider when it comes to software development, usually related to servers, hosting, domain registration, email, cloud computing fees, and office space. It is common for developers to do work on their own workstation and deliver the code via a service such as Github. Sometimes, however, there is the more complicated infrastructure required for the development process. If you anticipate a need for a physical development environment for your project, it should be agreed with the developer in advance who will pay for it.

A typical development server should not cost more than $20 per month, and anything over $100 per month should start to set off alarm bells. Software that is in development does not need the same level of infrastructure as a production system, so most cases should not require expensive development environments.

Pitfalls

Things that can create problems for a software project and cause it to come in late or over budget are not all necessarily unique to the software industry, but there are a few things that commonly create problems.

One common issue is the lack of documentation. When software is poorly documented or commented on, it is difficult for others to understand. This creates a time burden for anyone who comes later and needs to understand or work on the code. Poorly commented code becomes more expensive over time.

Another common issue is unmaintainable code. Code that is not easily upgradeable and maintainable will inevitably cost more money in the long run as the amount of labor required to keep up with the progress of the industry grows.

Inefficient code can also, in the long run, become more expensive due to the costs of operating the infrastructure it runs on. Certainly, efficient code costs less in the long run, although there is a break-even between hardware costs and labor.

Good code that is maintainable, efficient, and well documented will always be cheaper in the long run.

Conclusion

When it comes to the cost of software development there are no simple answers. There are many factors to consider, and the more information you have, the more likely you are to have a good outcome.

22 Nov, 19

Technical Debt: When to Accrue and When to Pay Down?

5 Jan, 18

6 Nov, 18

Software That’s Saving the Planet

Software Development Process Guide

Naveen Joshi

August 19, 2020

Hire a developer for your new app – that easy?

Customized software has become critical to businesses wanting a competitive edge. The early stages of developing a new piece of software can feel a little overwhelming. Fortunately, a variety of systems have been established that can make the process much, much easier. The process of software development has evolved over the last decade, with an emphasis on speed and efficiency.

Describing the state of affairs in 2005, Martin Fowler, Chief Scientist of ThoughtWorks, wrote, “Most software development is a chaotic activity, often characterized by the phrase ‘code and fix.’ The software is written without much of an underlying plan, and the design of the system is cobbled together from many short term decisions. This works pretty well if the system is small, but as the system grows it becomes increasingly difficult to add new features to the system. Furthermore, bugs have become increasingly prevalent and increasingly difficult to fix. A typical sign of such a system is a long test phase after the system is ‘feature complete.’ Such a long test phase plays havoc with schedules as testing and debugging is impossible to schedule.”

The foundation of “modern” software development is based on two primary philosophies, the Agile Development Software Manifesto and the development of DevOps infrastructures. The primary goal of Agile is transforming the development cycle into a collaborative process, promoting flexibility, and assuring everyone on the team is on the same page, streamlining communications and eliminating confusion. DevOps focuses on developing and improving products faster than competing organizations by eliminating communications breakdowns between the operations team and the development team and having them work together. DevOps and Agile philosophies share fundamental goals, but use slightly different tactics in achieving them. Both philosophies promote the use of automation.

Knowing the Different Phases of Software Development

Though there is no “one method” for developing software. Typically, it goes through a series of standardized steps, or phases sometimes referred to as a ‘software development life cycle.’ Following these steps can help assure the quality of the software. The use of a standardized system streamlines the development process by minimizing confusion and maximizing efficiency. The basic steps for software development are listed below:

Understanding the problem– To develop a fully functional software solution, it is important to fully understand the problem, plus any additional requirements the organization may have. This aspect of software development is considered by many to be the most crucial part of the development process.

Planning– The team organizes and lays out a plan for software development. Estimates are made regarding the costs and resources needed for developing the software. This step may be merged with the Feasibility Analysis. At this time, the team can determine the project’s feasibility – where they can avoid wasting time and money, and how to implement the project, with the lowest risks and expenses.

Feasibility Analysis– This step determines whether or not the project is feasible to work on. It also details the risks involved and provides sub-plans for softening those risks. (No one wants to pay for a project that cannot be completed.)

Design and Prototyping– This stage of development involves the software’s entire architecture, which includes user-friendliness. It should be designed so users/customers can get the best outcomes. (Design does play an important role when attracting visitors and potential customers.) Running into snags and unforeseen problems at this stage almost guarantee cost overruns and may result in a collapse of the project. A prototype (a preliminary first model) should be included during the planning phase. However, even after its release, the first version can be viewed as a prototype, capable of further development.

Coding– The designing and writing of code for computer operating systems, computer or smartphone apps, and other devices.

Software Testing– New software typically undergoes a variety of testing phases before being implemented, or sold to a customer. At this phase, glitches and bugs are found and fixed. “APM tools” are becoming popular for testing purposes.

Maintenance– Many organizations include long-term maintenance in the software’s programming.

Best Software Development Methodologies

The Five Popular Software Development Processes

Factors such as the project’s size, the team’s strengths, and weaknesses, and other issues, will help to determine the best development processes for the project. All organizations set up their software development systems in different ways, and each project is handled differently, as well. Despite these differences, nearly all organizations develop software using a variation of one of the following five systems, or a combination of them.

Waterfall

The Waterfall development process is one of the oldest, “least flexible,” and most established models used for building software. It is often described as a “plan-driven” process and requires knowing everything needing to be done, in the correct order, before doing any development. Because of its rigid planning structure, the Waterfall development process should not be used in situations subject to radical change. The Waterfall process works best when goals and requirements do “not” change during development, and the original plans are followed.

The Waterfall development process “does not support” the testing of new products, user feedback in mid-stream, or a dynamic development process. However, techniques, such as continuous integration and deployment can eliminate many many of these issues.

Agile and Scrum

The Agile development process (and Scrum, its most popular methodology) uses a repetitive and dynamic approach. Unlike the Waterfall process, which uses a strict, tightly controlled, sequential flow, Agile uses cross-functional teams that “sprint,” focusing on the project for anywhere from two weeks to two months. (Projects should have a dedicated Scrum Master to ensure sprints and milestones are achieved.)

In Agile, cross-functional teams work in “sprints” for 2 weeks to 2 months, to build and release usable software to customers for feedback. Agile allows organizations to move more quickly and to test theories quickly, and without a significant investment. Testing can take place after each small evolutionary step and makes it easier to detect bugs or return to an earlier version if a problem develops. Unfortunately, Agile’s dynamic nature sometimes causes projects to take longer than anticipated, and to go over budget.

In response to early criticism of the Agile development process, Jim Highsmith, of the Agile Alliance, stated, “The Agile movement is not anti-methodology, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.”

Incremental and Iterative

These software development processes offer a middle-ground between the rigid planning of the Waterfall process and the flexibility of Agile. Both processes apply the concept of creating small amounts of software and then presenting them for feedback to different users. However, they differ dramatically in “what” is created.

In the Incremental process, each “incremental” improvement of the product adds one new function or feature. In essence, it is similar to creating an overall plan, developing an MVP (minimum viable product, a version with just enough features to satisfy customers) with core functionality, and then using feedback for developing new features. With the incremental process, early feedback on core features is used to make improvements.

In the Iterative process, each product released comes with a version of all planned features. The process focuses on a simplified implementation that progressively becomes more complex with each added feature until the final version is complete. With the Iterative approach, users gain an early viewing of what the final product could look like, and provide feedback.

The V-Shaped Software Development Process

This is a spin-off of the classic Waterfall method, but “does” support the testing of new software. Instead of working sequentially during the development process and saving all testing for the end of the project, a rigid “validation and verification” procedure follows each phase of the V-shaped development process, with requirements being tested before moving on. It works well for teams working on small projects with a tight focus. Instead of risking following a plan that finds problems at the very end of development, it offers opportunities to test during the development process. This is still a “plan-driven” process, and not for teams wanting greater flexibility.

The Spiral Software Development Process

This method merges the V-shaped process of a focus on testing with the incremental qualities of Incremental, Iterative, and Agile. Once a plan has been developed for a specific iteration, an in-depth risk analysis is done, identifying errors or areas of risk. For example, the plan has a feature that hasn’t been used or tested by customers. This feature can be developed as a prototype, and provided to users for feedback before shifting to full development. As each new feature is completed, the range expands further outward (like a spiral).

This process reduces risk. If a large or critical project requires significant documentation and validation during development, this might be the best choice. This process can also be useful when dealing with a customer who isn’t completely certain about their desired requirements and is comfortable with large edits during the software’s development.

AI and Software Development

Finding and hiring a development company can be difficult. While customized software has become critical to business competitiveness, a shortage of software developers has become a problem. Artificial Intelligence can help by performing many tasks much more quickly than a human could.

According to David Schatsky, managing director of Deloitte, AI is “having a remarkable impact on the software development process, such as reducing by half the number of keystrokes developers need to type, catching bugs even before code review or testing and automatically generating half of the tests needed for quality assurance.

“Researchers have discovered that machine learning and natural language processing can be used to analyze source code and other data about software development, such as records of project schedules and delays and application defects and their fixes. This makes it possible to automate some of the developers’ work. A new generation of AI-powered tools is emerging, guiding and empowering software professionals to produce better requirements documents, write more reliable code, and automatically detect bugs and security vulnerabilities.”

26 Jun, 20

17 Mar, 20

Continuous Integration and Deployment in Agile

22 Nov, 19

Continuous Integration and Deployment in Agile

Naveen Joshi

March 17, 2020

Within the last several years, the average lifespan of an S&P 500 company has been drastically reduced from 60 years to a mere 20 years, and it’s reported that the crux of the issue is the rapidly changing technology field. Any organization that hasn’t embraced technology and its myriad of constant change are destined to fail, according to researchers. Technology is an umbrella term that describes any machine-driven process, but within this broader term is the dependence of software. Software drives many critical functions within an organization and as an application becomes more complex, it’s difficult to rein in the many changes, bug reports, new feature deployments, and contributors to the codebase. These challenges are why development teams have adopted Agile methodologies, which can streamline the software lifecycle and offer continuous integration and delivery without the limitations imposed from previous ways corporations managed development.

Waterfall Methodologies are No Longer Optimal for Development

When you hear about Agile, you usually hear it compared to older Waterfall methodologies. Waterfall methods were popular – and still are with some projects – when the software was less complex and continuous integration wasn’t an issue. The older application had a smaller codebase, it might have only a few dozen features, and quality assurance (QA) people could test it soon after it was developed.

Waterfall methodologies are still useful for small projects where only a few features are developed into the application, and very few changes are made in future versions. Small projects with few changes don’t usually need continuous integration, and every phase of the lifecycle (e.g. design, development, testing) only needs to be done once before deployment. An application’s development success also relied on a small scope well defined during the design phase, and changes to scope were limited.

To avoid common pitfalls with Waterfall, project managers, engineers, and other gurus came up with several methodologies and practices that speed up new development, versioning, and bug fixing. Continuous integration (CI) and continuous deployment (CD) along with Agile eliminate many of the old school Waterfall disadvantages and add efficiency and speed of deployment to the software lifecycle.

What is Continuous Integration and Continuous Deployment?

Before getting into Agile and CI and CD, you should first understand the process and how it can improve your current software lifecycles. These current methodologies allow for quicker updates and revisions during the software lifecycle and free up developer time for new software versions and features. Continuous integration (CI) is the process of taking newly committed code and automatically adding it to a testing and staging environment for QA. The testing phase could be automated as well or human tested. In many organizations, both automated and human tests are used to validate software version stability before deploying it to production. Deploying buggy code loses customer trust, so several tests are done before code is sent to production. This was traditionally done after developers uploaded code to a testing environment, but CI does this as New Code is added to the main repository.

Continuous deployment (CD) adds an additional step to the automation process where code is sent to production after it passes a series of tests. Only if testing fails will code be sent back to developers, and the automation process will remove it from the next deployment. Once developers fix any issues, the process is repeated until it’s finally sent to production. With both CD and CI, integration of the latest software upgrades happen faster, are seamless to your users, and help development teams become more agile.

How Continuous Integration and Deployment Get You to Where You Want to Be?

Every application starts with an idea and goes into development with (hopefully) a plan. Even the simplest software could be subject to a lifecycle with revisions and improvements added in future versions. CI and CD make these versions happen faster with less effort required from the development team so that they can focus on the code.

Faster versioning and upgrades happen due to the nature of CI and CD. After a developer commits code changes, a build is automatically executed that creates a test version of the application. Testing is automated (unless the organization chooses an additional manual testing step), and a “Success” or “Fail” message is generated. If the message is “Success,” CD automation takes over and deploys changes to production. If a “Fail” message is presented, notification to developers, leads and any managers is sent. This lets them know that testing failed and why so that they can continue to improve the code until it passes QA tests.

The key to both CI and CD is automation, but each step in the lifecycle will seem familiar to a development team that has their process already in place. The steps in CI and CD are as follows:

Build and compile code committed to the codebase by developers.
Run unit tests on the code to find errors.
If no errors are found, move the code to a staging environment.
Tests are again run against the codebase using scripted tests, manually tested by a human, or both.
If CD is also a part of the environment, then the tested code is deployed to production.

If any of the testing steps fails, automation stops at the point where errors were found, and developers are notified that their code must be revised. Note that continuous deployment is differentiated with continuous delivery by one distinct difference – continuous delivery uses manual deployment to upload changes to production, but continuous deployment automates this step. For the best and fastest software lifecycle, developers aim to integrate continuous deployment into their process to make it more efficient. However, with large version changes, a development team might opt to manually deploy to production instead. There could be additional steps to deployment for large version changes (e.g. a one-time server configuration changes), or changes might need QA approval from a stakeholder before they are considered complete.

Before Using CI and CD, Understand the Pitfalls

Before getting into Agile methodologies and continuous integration and deployment, it’s important to recognize when these procedures aren’t viable for your project or when it could damage the end-product.

If an application already requires heavy maintenance and bug fixes, CI and CD could become too much overhead. For example, if your application becomes very complex, has several moving parts, and developers cannot take the time to fix issues found with automated tests, it might be better to focus on fixing all bugs and then deploying after they have all been resolved.

Extremely small projects might also not benefit from CI and CD. They could still benefit from Agile, but CI and CD might be too much overhead for small projects. For instance, if you have a simple one-screen desktop application that only performs a few functions, it might not make sense to include CI and CD.

Adapting to Agile and Continuous Integration and Deployment

A simple way to describe Agile is that it has the main components of Waterfall methodologies, but these phases are broken down into sprints and allow for flexible changes during development. These sprints break down development into small sections where each developer works on a section that could take anywhere from a few hours to several weeks to complete. After a component is completed, it’s sent to QA for testing. After testing, a project manager reviews results with stakeholders who either sign off on progress or ask for changes. If changes are required, the section of the application is sent back to developers to design requested changes into each feature. With Agile and large applications, the development lifecycle may never have an ending as features are always in the process of being designed, developed, tested, tweaked and deployed continuously.

Continuous integration and deployment are a critical part of Agile methodologies when flexibility and speed are necessary for an application with frequent changes and many deployments. Most development teams take parts of Agile and compile their version of it, but continuous integration and deployment are always the foundation for successful implementations. By using Agile for continuous integration and deployment, the development team reduces risk, speeds up every aspect of development, and becomes flexible to changes to satisfy stakeholders.

If your team isn’t already using Agile, converting to its methodologies takes some time and planning. It’s much different than Waterfall and takes more team effort and collaboration. Scrum and Agile are often conflated, but you do not need to hold Scrum meetings in addition to following Agile procedures. Scrum is often combined with Agile with large applications to ensure development success, but it’s not necessary. Every development shop has its Agile hybrid system that works for the team.

The most notable phase in Agile is designing an app step where Planning Poker creates a game out of time and effort estimates. In this phase, cards are given to each developer with numbers that represent the effort required to complete a component of the application. A component is presented to developers, each developer plays a card and the effort card played the most is voted in as the dedicated hours needed to complete the application component.

After effort is established, sprints are created by a project manager or lead developer. Sprints are broken down into days, weeks or months depending on the development effort translated into the number of hours. After each sprint, the developers meet to discuss their progress with the same lead or project manager (PM). The lead or PM can then create spreadsheets and graphs that let key stakeholders know progress for the application and estimate a time for delivery. Specifically, a PM creates a Burndown Chart that displays team velocity, which is the amount of effort completed and the pace at which a project is developed.

During sprints, the development magic happens but no lifecycle would be complete without testing. After a developer completes a sprint, the result is sent to QA where testing is done either using scripts, manual testing or both. If all is good from testing, it’s sent to deployment. Specific deployment days can be scheduled, but continuous integration releases updates as developers complete them. Continuous integration speeds up development so that business stakeholders no longer need to wait for the rest of the application to be finished before seeing results.

With continuous integration, a truly Agile development team can offer continuous deployment. This step takes more organization, testing and most of all automation of the deployment process. In traditional development, deployment days are once a month or (at most) once a week. Continuous deployment automation updates applications after they pass QA. Instead of getting updates every few weeks, stakeholders have immediate changes uploaded to the application rapidly with little effort from developers who traditionally must back up, upload and review changes after deployment.

Continuous Integration Means Better Performance and Productivity in Software Development

Combining Agile and continuous integration takes time for a team to adapt, but overall it benefits the organization and its requirements to rapidly change due to technology’s fast-paced industry movements. Agile is the foundation for how development gets done, and continuous integration accounts for rapid changes in an application’s design and features.

If your team hasn’t already implemented continuous integration and Agile, it’s missing out on a success rate of two-times more than traditional methods. Taazaa being reputed software development company incorporates both Agile and continuous integration to ensure all customers and their respective organizations achieve flexibility in software design, better communication among stakeholders and developers, and continuous migration of new software for increased staff productivity and sales.

25 Sep, 19

Building Distributed Applications

10 Nov, 19

22 Nov, 19

Asynchronous Strategies in C# Web Applications

Why migrate ASP.NET legacy apps to .NET Core?

Naveen Joshi

February 10, 2020

development, technology

Before we start with why we should migrate from legacy .NET Framework to .NET Core, let us discuss what these frameworks are and their brief history.

.NET Framework is a software programming framework supporting languages like C#, F#, VB.NET, etc. The first version of .NET Framework (version 1.0) was released on February 13, 2002. Since then there have been multiple releases and many success stories around it. The last version 4.8 was released on April 18, 2019, and this is the last feature version. Going forward there will not be any feature upgrades to .NET Framework.

The reason for discontinuing any further development in the .NET Framework is the birth and tremendous success of .NET Core.

A brief history of .NET Core

.NET Core is the open-source and cross-platform successor of .NET Framework. .NET Framework can run only in Windows, whereas .NET Core is built to run on every possible platform, including but not limited to Linux, Windows, macOS, Raspberry Pi to name a few.

.NET Core is licensed under the open-source MIT License. The first version of .NET Core was released on June 27, 2016. Since then six versions of .NET Core were released, with version 3.1 being the latest version. Due to being an open-source framework, it provides a faster and better opportunity for innovation.

With .NET Core 3.0, Windows Forms and WPF (Windows Presentation Framework) are now also available in .NET Core. This has filled the gap due to which desktop applications could never adopt .NET Core earlier. Pre .NET Core 3.0, we could only build server-side applications in .NET Core. Post .NET Core 3.0, from server-side to desktop, we can build any type of application in .NET Core.

.NET Core is getting adopted very fast, and for obvious reasons, some of which we will discuss in detail later in the blog. According to StackOverflow survey conducted for 2019 .NET Core tops the most loved in Framework, Libraries, and Tools category. Even exceeding PyTorch which is an open-source Machine Learning framework for python.

In the industry, organizations are converting their .NET Framework applications to .NET Core to take advantage of all the features it supports and improvements it promises. But before going into the advantages of the .NET Core, let us discuss what are the major drawbacks with legacy .NET Framework.

The main drawbacks with .NET Framework

Limited innovation:

.NET Framework 4.8 is the last major release version of .NET Framework. Going forward there will not be any new feature implemented in .NET Framework. Only bug fixes and security patches will be provided. Meaning there will not be any innovation in the .NET Framework anymore. Tough Microsoft mentions that they will continue to support the .NET Framework, but that does not mean making it compatible with the new and emerging technologies.

For example, if there is a new managed distributed database announced by AWS, it will not be guaranteed to have a NuGet package supporting the .NET Framework. Whereas it will definitely have support for .NET Core. The open-source community is very fast in adapting to new and emerging technologies, hence the possibility of a Nuget for .NET Core is higher compared to legacy .NET Framework.

Also, the new language changes in C# will only be available in .NET Core. Similarly, other innovations in Web (ASP.NET Core), as well as desktop frameworks (WPF), will happen only in .NET Core.

The Talent pool:

At present, the talent pool for .NET Framework developers is probably more compared to the .NET Core developers. But developers are more interested in joining a .NET Core developer role rather than .NET Framework developer role.

We did a little comparison of jobs in dice.com for .NET Core and .NET Framework. And as of writing this blog, for .NET Core, there are 2,394 Jobs, whereas for .NET Framework there are 2,398 Jobs. Both the results are very close. Meaning 50% of jobs in demand today are for .NET Core. This also shows the supply and demand for both legacy .NET Framework and .NET Core are almost equal at this point.

Today most of the blog content and YouTube channel focus on .NET Core, making it the framework of choice for new developments.

Cost of legacy systems:

The only option of running a Legacy ASP.NET Web applications is in an IIS Server running in a Windows Machine. Even if we do self-hosting of the ASP.NET Web application, we will still have to have it running inside a Windows Server. The cost of a Windows Server license is very high compared to a Linux Server.

For example, in AWS if we take a T3.2XLarge server, one running Windows and other running Linux, the difference in monthly cost is approximately $107.75 (lower cost for Linux). Which gives us a cost-saving of $1,293 per year if we use Linux.

If we run the equivalent price comparison in Azure, then an A2 Windows Server monthly cost is $131.45. Whereas for an A2 Linux Server the monthly cost is $87.65. That is a $43.8 monthly savings. Annually a saving of $525.6.

Now, we can run an ASP.NET Core Web application in the Linux server and realize the savings.

Another important, but not obvious savings for ASP.NET Core application comes by using Docker containers. A legacy ASP.NET application can have only one instance running in a Windows Server, in which case it might not use the resources optimally. On the other hand, .NET Core applications can run in Docker container, and we can have multiple containers running the same application or different applications inside a single Linux server, intern utilizing the system resources more optimally. Hence optimizing cost.

The other cost is associated with not having enough innovation in legacy .NET Framework. Using the latest tools and frameworks becomes harder due to a lack of support. Hence, a lot of custom development and cost.

Security Risks:

Given the fact that Microsoft has a complete focus on .NET Core and does not intend to make any feature change to .NET Framework 4.8, there is always a risk of security running in .NET Framework versions. Tough

Microsoft clearly mentions that they will continue to provide security patches to .NET Framework 4.8, but .NET Core always has the advantage given its open-source nature and being actively developed.

Advantages of .NET Core

Performance:

ASP.NET Core Web Application is much faster than legacy ASP.NET Web Application. As of the day of writing this blog, based on tech empower performance tests, ASP.NET Core running on Kestrel Web Server on Linux, is 7th (Cloud test) and 8th (Physical box test) in the list of fastest Web applications. These tests are running on Linux box. So they also have legacy ASP.NET running in Mono in Linux (Nginx Web Server) as part of the tests. And legacy ASP.NET is currently in number 351 on the list.

In Database connectivity, ASP.NET Core Web Application running on Kestrel Web Server on Linux and making a single SQL query in a PostgreSQL database is on number 28th of the list. For the same test, legacy ASP.NET running in Mono in Linux (Nginx Web Server), connecting to a MySql database and making a single SQL query comes in number 399 of the list.

For JSON serialization, ASP.NET Core Web Application running on Kestrel Web Server on Linux is in number 11 in the list. Similarly, a legacy ASP.NET Web Application running in Mono in Linux (Nginx Web Server) is in number 356 in the list.

Note: Test number (Round 18) dated 07/09/2019

From these results mentioned above, you can see ASP.NET Core applications are significantly faster than legacy ASP.NET applications.

Cloud and DevOps:

.NET Core is built with Cloud in mind. Till .NET Core 3.0, it was only supporting server-side programming paradigm, such as ASP.NET Core, ASP.NET Core Web API, etc. And from day one, .NET Core Web applications were equipped with the tools and support to run on docker containers. And as we all know, to run an application in the cloud today is to run in a container. At least in the Linux world, as it is extremely cost-efficient easy to scale.

How does this help? Well, managing a container-based application is extremely easy. Plus, creating a container from scratch and starting it to serve web requests happens within a few seconds, compared to traditional virtual machines (where we usually host legacy ASP.NET applications), which takes in double-digit minutes. Hence, scaling out a container-based application is instantaneous and easy to manage scale as well as cost.

Apart from that, the cloud providers, as well as in-house data centers, can manage containers with ease using open-source container orchestration engines like Kubernetes or using the offerings by the cloud providers. For example, AWS provides both managed Kubernetes (Amazon Elastic Kubernetes Service (Amazon EKS)) as well as its own managed container service (Elastic Container Service (ECS)). Similarly, Azure provides both managed Kubernetes (Azure Kubernetes Service (AKS)) as well as its own managed container service (Azure Service Fabric).

Support for Modern Architecture:

One of the modern architecture that is becoming extremely famous is a microservices architecture. And .NET Core makes it ideal to build microservices. To dig more into it, let us first define what is a microservices architecture.

Microservices architecture is a pattern for building highly scalable services. It is the opposite of a monolithic architecture. In a monolithic architecture, an entire application is part of the same .NET Project/Solution and is available in the same source repository as well as a single hosted service. However, microservices architecture is the complete opposite. In a microservices architecture, every service is a single responsibility service and providing only one functionality in a business domain.

For example, in very simplistic terms, in an e-commerce system, a service managing only user logging, can be considered as a microservice. Whereas in a monolithic architecture, the entire e-commerce system will be exposed as a single service (or a couple of services, in most cases a single one).

For us, the biggest feature a microservice provides is the ease of deployment. Because microservices are meant to be independently deployable, of course, we have to design it to do that. Apart from that, microservices are loosely coupled, highly maintainable (due to smaller size and single responsibility) and highly testable.

Since microservices are smaller in size, hence a single application is usually broken down into multiple microservices. And due to this, these are usually deployed in Docker containers and managed through a container orchestration engine. The reason for going with containers is that the services can be scaled independently of each other and on-demand based on request volume.

Given the support for Docker container from day one, ASP.NET Core becomes an obvious choice for building microservices architecture. And in Visual Studio 2019, the ASP.NET Core application builder comes with support for Docker in the IDE itself. And creates all the required scaffolding during the project creation. Which makes it really easy to get started with a containerized microservice in ASP.NET Core.

Security Advantage:

There are two types of security to consider. One is how vulnerable .NET Core itself. On that front, since .NET Core applications can run on Linux servers, they inherently get all security advantages of running in a Linux server.

The second aspect is securing an ASP.NET Core Web Application. Well for that, there are plenty of options available. Including Custom Authentication mechanism (using Authentication Handlers), JWT (JSON Web Token) Authentication, OAuth. And finally, third-party authentication providers, like Google, Facebook, Etc. And all these can be built with few lines of code and existing Nuget packages.

Now that we understand the advantages of jumping into .NET Core boat, let us take a look into the ways to migrate an existing legacy .NET Framework application into .NET Core application.

Legacy .NET Framework to.NET Core Conversion

In our opinion, there are two approaches to conversion. The first approach is to use tools to port from the .NET Framework to .NET Core. And the second approach is to re-write with porting (now don’t get anxious, we will explain in detail in which scenario it makes sense).

First Approach of porting:

In this case, we will follow the following steps, one thing to keep in mind, there is no magic here, there will be some rewrites and reworks based on project complexity:
● Firstly, we will re-target all projects to .NET Framework version 4.8 (the latest version). This will take us close to .NET Core in a sense of API portability.
● Secondly, we will use .NET Portability Analyzer to find out API in our current legacy .NET Framework project which is not supported in .NET Core. At this point, keep the list of alternative API in .NET Core, so once we move our code over to .NET Core, we will use the new set of API.
● Thirdly, create a new .NET Core project (based on existing project type, it will either be a Class Library, Console or Web API. NOTE: If we are moving over a WebForms project, we will have to re-write the UI layer in MVC Razor syntax, tough we could reuse all the HTML, JavaScripts and CSS).
● Fourthly, copy all the files into the new project, and add the necessary NuGet packages into the project (in our experience, we have not seen any gap in NuGet packages between legacy .NET Framework and .NET Core).
● Finally, rework wherever needed due to non-availability of legacy API (here we will use the list of alternative API’s from step number 2).

Microsoft’s approach for porting a legacy .NET Framework application to .NET Core is available here.

Second Approach of re-write with porting:

We would suggest this approach if you have a monolithic service. In that case, we can take one domain-specific functionality at a time and convert it into a microservice. And during this process, we can take the existing code and follow the first approach and port only part of the monolithic service into a microservice built-in .NET Core. And in the process, we can also ensure we are using modern design practices like SOLID principles if it is not already followed.

With this approach of converting one responsibility of a monolithic service as time into a .NET Core microservice, we will derisk the entire process significantly. And also will have significantly low-cost testing and deployment strategy.

Conclusion

Given the advantages provided by .NET Core over legacy .NET Framework, its a no brainer to upgrade. But as with every upgrade project, we have to be mindful of the cost. In our experience, with an experienced software developer team and following a step by step breakdown of an existing application and porting into pieces become very cost-effective as well as less risky.

If you take a big application and want to convert in one go, well it is not impossible, but it is hard. And also chances of paying some of the technical debt is possible due to the pressure of delivery.

Whereas if we break an application into smaller microservices and/or components, we have a better chance of success. And as and when we go with the conversion, we can follow the current design principle and best practices along the way.

15 Mar, 18

10 Apr, 19

Why Microservice Architecture?

23 Jul, 19

NoSQL or SQL – How to Choose the Best Fit for a Project?

Naveen Joshi

July 23, 2019

Asynchronous Strategies in C# Web Applications

Data persistence has always been a key challenge faced by software developers and programmers. Several database management systems have been introduced since the beginning of electronic computing in order to handle data persistence issues in software products. Relational database management systems, powered by SQL, have ruled the IT industry for more than four decades, though the advent of NoSQL database has triggered a new debate regarding whether to choose SQL or NoSQL databases.

Why NoSQL Databases were Introduced?

It is important to mention here that SQL-based RDBMS are highly structured, in which data is stored in the form of well-organized tables with associations among them. This data is queried using a structured query language. There are, however, certain limitations with this approach. Today, the magnitude of data that needs to be handled is enormous. Also, data coming from different sources is versatile. Therefore, conventional SQL-based DBMS are not suited to handle this enormous and versatile data. To combat this, NoSQL database management systems were introduced which address the aforementioned concerns.

NoSQL or SQL – Factors Affecting the Decision

While deciding whether to choose NoSQL or SQL based DBMS for a particular project, the following are some of the considerations that should be taken into account.

1 – Type of Data

Choosing a database depends majorly on the type of data that your project needs to store. If your data is highly structured and associations among the program entities are clearly defined (for instance, if you are developing a point of sale system where you need to store customer orders and product records), conventional SQL based databases are the best fit.

On the flip side, data from molecular modeling, Geo-spatial information, and satellite data are highly unstructured. Likewise, data from social media analysis and websites is also highly unstructured, and relationships among the data entities are not clearly defined. In such scenarios, NoSQL is a better choice. For example, a data mining application should utilize the power of NoSQL database rather than conventional SQL.

2 – Database Volatility

Software development is an agile process where requirements can quickly change, which affects the database schema as well. It is almost impossible to correctly implement the database schema in the first shot. If persistent data of the project is more likely to change in the future, NoSQL databases are a better option since they don’t have any rigid scheme which makes them more suitable for such projects.

3 – Time and Cost

Time is crucial in the software development life cycle. In the past, companies hired dedicated database administrators, while software developers mainly focused on application development aspects. However, this decoupling of DBA and software developers resulted in increased software development time and cost as well. NoSQL technologies such as JSON allow software developers to integrate data and development perspective, leading to cost-effective and timely delivery of software projects.

4 – Scalability

Scalability is one of the significant issues with SQL based databases. With the huge magnitude of information needed to be stored, data size grows exponentially. SQL-based databases undergo vertical scaling, which is extremely costly. On the other hand, NoSQL DBs scale horizontally and scalability issues can easily be handled by adding another node in a database cluster. Google’s HDFS scaling systems is one example.

5 – Data Mining and Machine Learning Perspective

Data mining and machine learning are processes of analyzing data in order to extract useful information and patterns which be used for the decision-making process. These techniques are usually applied over enormous and extremely versatile data. Therefore, in such projects, NoSQL databases are a better choice.

What to choose: NoSQL or SQL?

Having studied the factors that affect the decision, the answer can easily be found. If the project is expected to see drastic changes, needs to handle the huge and versatile amount of data, or the database entities and scheme is ambiguous at the start, go for NoSQL. However, if the project needs to handle small and homogeneous data, and the databases entities are clearly defined with unambiguous relationships (which rarely is the case), SQL is a good fit.

15 Mar, 18

10 Sep, 19

Augmented and Virtual Reality Coming of Age

14 Sep, 19

5 Bootstrap Layout Tips for UI Challenged Developers

Why Microservice Architecture?

Naveen Joshi

April 10, 2019

development, technology

For years, software developers were tasked with maintaining and building monolithic applications that spanned their entire user-base. Monolithic applications could be modular, but ultimately every moving part affects the entire application. When coders deployed new code, QA had to test the entire application to ensure stability. Microservices changes the way applications are developed, and they make each moving part much more independent so that one change to a container only affects one component of your environment.

Understanding Old-School Traditional Programming

Most of the legacy applications still on the market have a monolithic code-base. Some of them have a global presence and others are applications that power large corporations. Google’s code-base is monolithic. Every time a change is made to their algorithms, it’s deployed to production. When mistakes happen, it affects the index as a whole.

Other organizations keep their software private because it drives their business model. It’s not uncommon to have a large application powering customer service, sales, shipping, marketing, business, and finance from one code-base. When changes are made, they affect the application as a whole.

Monolithic programming can be stable, but it takes a good QA team and programmers with full understanding of the entire system. This can be problematic as businesses add new programmers to staff. New developers make changes to methods in the code base, and it’s not uncommon for them to accidentally introduce bugs in other parts of the application just from a misunderstanding with how these changes affect other business components.

Another issue with monolithic applications is that the code-base expands so much that it can be difficult to maintain. More bugs are introduced as developers are working with different parts of the application without knowing what the others are working on. The situation can turn terrible for the organization that can lose large amounts of revenue for bugs big or small.

The Introduction of Microservices

Microservices solve many of the problems associated with monolithic development. Where monolithic programming uses one core code-base, microservices separate this aspect into independent moving parts. With microservices, the application works independently of others, so changes and feature additions affect the service only and not the entire code-base spanned across several services.

Going back to the components of a business application, microservices would introduce a new architecture that would run independently of each other. Sales applications would run in one container while customer service runs in another. When developers add features to the sales application, it’s completely separated from other applications that control other business units.

Containers run each microservice, and they allow them to be fully automated during deployment. With monolithic deployments, a large application can take hours to update. The business usually has one person (or a team) deploy the application, have QA test it, and then deploy it piece-by-piece to every server. The team can install some automation software to make it easier to deploy, but it takes time to build these scripts and they must be monitored by the person deploying the application.

Even though microservice components run independently of each other, it doesn’t mean that they cannot communicate. Separating a monolithic application into independent components would be worthless to the business because each application still needs to communicate. Every sale made in a sales application must communicate with customer service to deal with customer issues and then with shipping to send the order. It also needs to communicate with a financial application to ensure that the business is paid.

Before you think that they cannot communicate, we introduce the idea of APIs. API is a general term giving to an interface that can be used to provide information to an application that then provides feedback. A Microsoft Windows operating system has an API that developers use to work with the operating system. Facebook has an API where developers can interact with Facebook activity. Salesforce is a global platform with an API that creates powerful interfaces for salespeople. All of these applications are separated from each other, but they provide APIs where developers can integrate them into their own software.

Containers are similar in that they can hold component applications using APIs to interact with each other. These applications have their own separate business logic coded into them, so the integrated outside software can only swap data instead of having its own code-base affecting the way the application runs. This is the main advantage of containers.

Automation and Docker

If you’ve looked into containers, you’ve probably seen Docker referenced. Docker is one of the leading containerization platforms on the market, and it allows developers to host applications in the cloud.

Docker has automation for deployment built into it. It works directly with GitHub, which most developers use as their code-base repository. If your business doesn’t use GitHub, it’s time to give it a try, because it handles much of the versioning and documentation needed to host open-source software and distribute it to your user-base.

In the Docker documentation, you can set up a linked GitHub account with your Docker account to automate deployments. You may wonder about the advantage of automating deployment, and it’s difficult for businesses used to monolithic coding to understand its advantages. Most think that it could be destruction to the application, but in fact, it saves time and reduces overhead during deployment days. By automating deployments to Docker, you can rapidly deploy changes to the application without relying on staff. It’s good for applications and emergency patches when bugs are found, but it’s also resourceful and convenient for a busy development team.

.NET Core and Its Support of Containers

Another advantage of containers is that de-coupled applications can be written in any language that you want. With monolithic applications, the entire code base (usually) is built in one base language. When you work in any enterprise, you’ll notice that the developers focus on one platform. Large global enterprises might have a heterogeneous environment, but they have large budgets to support integration between different platforms. For small to medium-sized businesses, it’s common to focus on one core programming language.

Several businesses rely on Windows and .NET applications. To keep up with the evolving development environments, Microsoft introduced containerized .NET applications and offer a way for VB.NET or C# programmers to rapidly deploy applications to containers.

Microsoft sees containerization as a scalable solution for its developer applications. When you work with containers, you instantiate an image (create a container) you should deploy to different host servers on different fault domains. This allows failover should one fail, which creates scalability and sustainability.

With containers, the application runs on the target operating system. This is unique from VMs where any operating system can be used on the VM regardless of the underlying physical machines. However, the host server can be a VM which means that containers can run on any operating system running on the target virtual machine.

Microsoft provides a test application that shows developers how to use containers using .NET and Docker. It’s also useful for developers tasked with migrating a monolithic application to container services.

Current Visual Studio versions and .NET core services support containerization, so setting up a development environment is as quick as installing the underlying .NET framework and Visual Studio software. Then the development team must shift its focus from one code base to a containerized image resource.

If you find that your monolithic software is buggy or getting out of hand, it might be time to consider a migration to containerized services. Since .NET supports the architecture, not much changes with the infrastructure. Only the code is changed to support the rapid deployment and separate services.

If you need to work with professionals, Taazaa can help you take control of your monolithic code and migrate to a containerized environment.

22 Nov, 19

Software That’s Saving the Planet

6 Nov, 18

5 Jan, 18

Technical Debt: When to Accrue and When to Pay Down?

Top Three Features of ASP.NET MVC 5

Naveen Joshi

February 15, 2019

development, insights

ASP.NET MVC is Microsoft’s latest web application development technology based on the principle of the separation of concerns. MVC stands for Models, Views, and Controllers, respectively. Prior to the MVC pattern, Web Forms was the prime Microsoft technology for web application development. However, Web Forms lacked the flexibility of development and loose coupling. MVC addressed these concerns. This article presents a brief overview of the top three features offered by ASP.NET MVC 5, which is the 5th version of the Microsoft MVC technology.

1- Attribute Routing

The major difference in ASP.NET MVC and ASP.NET web forms is the way incoming requests are handled.

In Web Forms, incoming requests map to a file or resource on the webserver. For instance, the requested URL can be of the form of www.abcd.com/xyz.aspx. Here, the URL refers to an ASP.NET Web Form named xyz.aspx, located at the root directory. There is a one-to-one mapping between the URL and the page that is accessed, which must physically reside on the server.

On the other hand, MVC routing pattern maps URLs with action methods, resulting in cleaner and more SEO-friendly URLs (for instance, www.abcd.com/xyz/buy). This URL refers to the action method “buy” of the controller “xyz” on the domain “abcd”.

To see where these routes are configured, go to the solution explorer of your ASP.NET MVC application and find App_Start folder and find the RouteConfig.cs file. It contains a method named RegisterRoutes which takes a collection of type RouteCollection as a parameter. Inside this method are routes that are to be ignored; routes that are to be added can be defined. This is shown in the following code snippet:

public static void RegisterRoutes(RouteCollection routes){
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{id}",
defaults: new { controller = "Home", action = "Index", id = UrlParameter.Option }
);
}

Apart from defining routes in the RouteConfig.cs file, ASP.NET MVC 5 has introduced a new feature known as attribute routing which allows developers to specify a route as an attribute of the action method. To enable attribute-based routing, you need to modify the RegisterRoutes method of RouteConfig.cs file as follows:

public static void RegisterRoutes(RouteCollection routes){
routes.MapMvcAttributeRoutes();
}

To add a route on any action method, you simple have to add an attribute named Route and pass the route as parameter to it. For instance:

[Route("Products/Sports/{id}")]
public ActionResult GetSportsItems(string id){
ViewBag.Id = id;
return View();
}

2- Default MVC Template replaced by Bootstrap

ASP.NET MVC 5 replaced the default MVC template with a much more flexible and standardize CSS library called Bootstrap. With the integration of Bootstrap in MVC 5, developers have got a myriad of styling options right out of the box.

3- Improved Identity Management and third party Authentications

ASP.NET MVC 5 has introduced a more robust, secure, and at the same time, a flexible identity management mechanism. Now with MVC 5, developers need not explicitly manage identity and authentication of the application users. Rather, these features come built-in with the framework and can be easily tweaked to achieve the desired identity and authentication operations. Also, MVC 5 provides authentication and logic features via third-party applications such as Facebook, Google, and Twitter, all of them right out of the box.

4 Oct, 18

Three Ways IoT will Revolutionize Our Homes

16 Aug, 19

Web-Based Single Page Applications – What Are They?

10 Apr, 19

Why Microservice Architecture?

Scala Performance Monitoring

Naveen Joshi

September 5, 2018

Web-Based Single Page Applications – What Are They?

If you are creating a website, web application or other web pages, you will likely need to do some coding. While some simpler alternatives do exist, coding is a necessity for many types of businesses, sites, and applications. There are many different programming languages out there that people use, with Scala being among the most popular.

While it would be nice if we could just code our app or site once and it would run perfectly for the rest of the time, that isn’t the case. We need to be sure to monitor the performance of our apps to ensure they are running correctly and not experiencing any hiccups that could affect your business or end-users alike.

Monitoring the performance of your applications is of the utmost importance to your business. Without performance monitoring, you run the risk of missing potential issues or problems with your code that could have easily been discovered and fixed in minutes if your business monitored the apps and code. This issues could ultimately leak into the user experience and could potentially cause some downtime, which can be extremely costly to businesses.

Now that you know about the importance of performance monitoring for your business, app, or site, what are the solutions available to you? If that is a question you are asking yourself, you have come to the right place. This article is going to take a look at some of the best solutions out there for Scala performance monitoring.

AppDynamics

Web applications created with Scala can sometimes have frustrating issues and mysterious problems that you might not quite know the origins of. If those are problems you find yourself dealing with, AppDynamics has a solution for you. The AppDynamics platform will provide you with a real-time look at how your Scala apps are performing.

They enable you to find the root causes of various issues in seconds, without the need for a ton of manual monitoring or overhead. Other benefits of using this solution are lightning-quick troubleshooting, automatically visualizing tendencies and charts that will help you to understand the health of your apps.

DynaTrace

Another solid solution for monitoring Scala performance is Dynatrace. Dynatrace is capable of detecting transactions from end to end and can actually show and visualize service requests, which is a great feature. Dynatrace is also able to show where (and how) your Scala app consumes CPU, and the platform can also learn the details of the architecture of your application.

The Dynatrace dashboard also gives you insight into a wide range of different performance metrics that are important to see and keep tabs on. Dynatrace also works incredibly quickly in only a few minutes to get you up to speed on the health of your Scala apps.

AppOptics

AppOptics is one of the most powerful yet simple options out there for monitoring Scala performance. You can set it up in minutes, and the platform can illustrate your app’s performance in real-time, with dashboards that show a variety of important metrics.

The platform also makes it easy to go from simple and visualized trends to deep, code-level analysis. The insights it provides can be very helpful for your business, and the platform features both out-of-the-box dashboards, or you are free to create and customize your own.

OverOps

Not only does OverOps help you to monitor the performance of your Scala apps, but it can also help you truly understand the root causes of any issues you may be experiencing. The Scala monitoring within the platform can be seamlessly integrated with your workflow and has a very low network and storage overhead.

It runs extremely lightweight and should only use about 1% CPU. The platform is also incredibly secure and can install in only a few minutes. It is a beneficial tool with several different benefits that all aim to help you keep your Scala app’s performance in tip-top shape.

In conclusion, we hope that this article has helped you understand how important performance monitoring is for Scala and any other programming language that you might find yourself using. While the performance monitoring solutions offered up in this article are not the only ones available, they are among the best and most popular options.

16 Aug, 19

10 Apr, 19

Why Microservice Architecture?

20 Jul, 19

You Should Be Tracking These Metrics to Have a Successful App

Asynchronous Strategies in C# Web Applications

Naveen Joshi

March 15, 2018