Cost efficient technologies

Cost efficient technologies

Nowadays the range of tools for web and mobile development is so wide that it doesn’t really matter which set you pick as long as you get the job done. When judging from the business point of view, the technology doesn’t matter, too. However, it can be really hard sometimes to decide in favor of a specific framework or a programming language. Hope our brief overview will help you reassure in a chosen cost-effective way around the jungles of languages, frameworks and platforms.  

Language specifics

A variety of programming languages turns the customer’s choice of the best solution into a question of personal convenience rather than a single correct decision. In JVM World: 1,2,3,4 and many more… Usually every developer has an individual preference when it comes to programming languages. Still, each choice has its upsides and downsides. Groovy and Kotlin currently experience some issues with the lack of tools for static code analysis, including security audits. Koltin is rather fresh, lacks large number of mature frameworks and the community are somewhat small. Java and Scala are way more prepared than its younger siblings. Java provides teams with access to vast amount of documentation and open source tools, what easily makes it the most applied framework that cuts development time and cost. The recruiting issues are crucial as well. Developers are easy to find when it comes to Java, not so easy for Scala and Groovy, and even harder for Kotlin.

Frameworks

The selection of a framework, on the other side, is a much more complicated process. Each separate case needs a well-selected framework which is endowed with just the right abilities for the task. The balance is a key – it can’t be too complex or too simple. For example, one won’t be building a simple CMS using microservices or designing a distributed cloud system using the monolithic approach.

Front-end solutions

There are many Single Page Application frameworks which can also be used for a project. The most popular are React with Flux implementation, Angular, Vue and Ember. React is the hardest one to set up when bootstrapping a project from scratch due to a huge amount of library picking that needs to be done. As an alternative, developers may go for a bootstrapped version of the framework, which will probably have its own obstacles. On the plus side, it’s usually easy to find the developers willing to work with this stack. Angular and Ember are quite simple to set up in order to start using right away. Although, with Ember, it will be harder to find the right people for a job.

Platforms and operations

The struggle between cloud-based SaaS and PaaS vs. on-premise approaches is still relevant. Heroku is considerably easy to get started with, it is ideal for the small project. But you will also hit some scaling limits after growth and will be spending lots of money on transition. Authentication services like Stormpath, Auth0, and Okta offer solutions that are easy and convenient, but once you reach a certain size, prices will get higher very fast. Sometimes it makes more sense to build your own solution – AWS Cognito provides the open set of tools for creating an auth service.

This variety of tools will allow you to build an affordable project in a quick timeframe. Krusche & Company experts are eager to help you make the cost-effective choice.

Cost efficient tech

These days in web programming it doesn’t really matter which set of tools to pick up to get job done. While all languages can be used, framework selection is quite a complex process.

Business never really cares about technology, every product has to work and needs to be developed within certain timeframe to comply with budget.

Frameworks are picked for specific use cases. No one will build simple CMS using microservices or try to design complex distributed cloud system using monolithic approach.

Language specifics.

JVM world. Java, Scala, Groovy, Koltin. Developers might have have their preference on any of these, business doesn’t. Groovy and Koltin currently have issues with amount of tools for static code analysis, including security audits. Koltin is very new and frameworks count as well as community is too small atm. Java and Scala are way more mature. Java being most used framework these days give development teams access to huge amount of documentation and OSS tools. Which leads to time/cost reduction. Resources – java easy to find, scala/groovy hard, koltin very hard

FE. There are number of SPA frameworks these days, most used ones are react + flux implementation, angular, ember. React is hardest to set up properly, to bootstrap project from nothing lots of library picking needs to be done, as an option devs might go for some bootstrapped version of framework, which might have it’s own problem. On plus side it will always be easy to find devs willing to work with this stack.

Angular on the other hand is very easy to set up and start using right away. But you will get a huge toolkit. Ember is similar, harder to find people though.

Operations. Heroku quite easy to get started with, it is fine for small project. Once it grows you will hit some scaling limits this platform provides and also spend lots of money on transition. Starting with something more sophisticated from start is usually good idea. Having scaling and smart orchestration in mind

Cloud SaaS services vs own build. Number of companies offer various solutions today. For instance auth services (Stormpath, Auth0, Okta). Again it’s quite easy to start working with them, but once you hit certain size prices will grow quite fast. Looking into developing your own toolkit might make more sense with tools like AWS Cognito, which provides bare set of tools to build your own auth service.

K&C will help you make correct choice
.

Agile team setup

In outstaffing it’s not always good idea to compose team using cheapest possible resources. 7-9 people usually ideal team size for large scale projects. Having all of these people as seniors is not quite cost effective.

Best team would consist:

2 senior devs which drive forward project architecture and tech

3-4 mid level developers which do main bulk of work

1-2 juniors which need to be maintained by rest of the team but can be assigned to simple and boring tasks

Bad teams

1 Senior dev acting as SM, 6-7 Junior devs. It would be nightmare to track all these devs
.

7 seniors, too expensive
.

Mixture of mid and juniors, moving project forward technologically would be really hard. Team might constantly make bad choices
.

Add comment

E-mail is already registered on the site. Please use the Login form or enter another.

You entered an incorrect username or password

Sorry that something went wrong, repeat again!
Contact us