January 23, 2013 at 9:13 pm
Comments posted to this topic are about the item Serverless Software
January 24, 2013 at 2:58 am
I partially agree.
Yes, developers should be develop software that can scale up and down as needed, but they still have to worry about the underlying 'hardware'. I put that between quotes, as using a cloud service does not mean you can just write any code. Suboptimal code can mean buying new bigger hardware, or purchasing more compute cycles, and both can be quite expensive.
January 24, 2013 at 4:24 am
I am always hopeful that the technology can continue to develop along the lines that single individuals can specify, develop, implement and maintain applications to any scale without necessarily having capital in place prior to development. Obviously cloud computing or this kind of distributed model certainly takes care of the scaling problems otherwise unavailabe to individuals.
To make abstraction truly powerful we may need to give up our protection of optimisation but I think optimisation will still be a requirement for some years to come.
Its my opinion that there is a big shortage of software engineers and the more developers we can empower the greater the likelihood that we can really leverage the ever increasing power of the hardware and get the truly great applications we need. I believe software design is lagging behind the speed of development of hardware. I hope that out of this we will all be able to progress towards a more complete understanding of software development.
cloudydatablog.net
January 24, 2013 at 7:55 am
Anytime I hear cloud computing, Hadoop, or Mongo DB I always think of this video (warning: contains profanity).
At home I connect to the internet with an aircard at $10 per GB.
In my company's customer base we have customers that are sharing a T-1 network among about 20 facilities with little chance of upgrade. We had customers that we connected to using a 56K modem as late as 2009.
If you are on the left or right coasts or major metropolitan areas high speed internet is there. The problem becomes apparent when you look at a night satellite picture of the U.S. If there aren't many lights there, probably the same with high-speed, dependable internet.
Developers should never have the newest computers or the hottest servers when developing. If they can get a program to work decently on medium equipment, then it should work decently for the customer.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
January 24, 2013 at 9:42 am
rharderwijk (1/24/2013)
I partially agree.Yes, developers should be develop software that can scale up and down as needed, but they still have to worry about the underlying 'hardware'. I put that between quotes, as using a cloud service does not mean you can just write any code. Suboptimal code can mean buying new bigger hardware, or purchasing more compute cycles, and both can be quite expensive.
I'm not sure that's worrying about the hardware. I think that's more writing better code, that efficiently uses whatever it's running on.
January 24, 2013 at 2:09 pm
Steve Jones - SSC Editor (1/24/2013)
rharderwijk (1/24/2013)
I partially agree.Yes, developers should be develop software that can scale up and down as needed, but they still have to worry about the underlying 'hardware'. I put that between quotes, as using a cloud service does not mean you can just write any code. Suboptimal code can mean buying new bigger hardware, or purchasing more compute cycles, and both can be quite expensive.
I'm not sure that's worrying about the hardware. I think that's more writing better code, that efficiently uses whatever it's running on.
I'm going to have to agree with rharderwijk. As an analogy, let's translate:
'Development shouldn't be concerned about the size or care of physical machines'
to
'Development shouldn't be concerned about the size or care of databases'
and see how that feels. Using, say, LINQ with all defaults and letting the software auto-build your table structures is essentially the same as letting the "service" do the same kinds of things.
First, it depends very much on what type of development, what industry, what resources are available, prioritization of requirements, performance targets now and in the future, product/project total lifespan, etc. If the developer/developer's employer doesn't care, then no, physical hardware, database engine, etc. may not matter much - this is the "take the defaults" approach.
For some kinds of development, it really does matter - can you use AES-NI instructions or not? Do you have X amount of storage available? Are there different kinds of storage, with different speeds? Are there added costs to certain things?
Creating an app that stores a handful of recipes for one user is not the same as a realtime control system for a pacemaker, which in turn is not the same as an enterprise HR platform (where "enterprise" is defined as 300,000 current employees).
Further, knowing about hardware allows you to have the option of choosing tradeoffs yourself - what's the native word size, and are there instructions that are much faster/slower, for instance. Not knowing about hardware means you cannot control those tradeoffs... and you may not even be aware of their existence.
January 24, 2013 at 2:28 pm
I am dating myself with this one but.....
Back when i was a mainframe programmer trainee, I was browsing thru an old source library. There I found an IBM assembler payroll program with the comment in one section: 'uses half word arithmetic to save memory'.
January 24, 2013 at 5:37 pm
Nadrek (1/24/2013)
Further, knowing about hardware allows you to have the option of choosing tradeoffs yourself - what's the native word size, and are there instructions that are much faster/slower, for instance. Not knowing about hardware means you cannot control those tradeoffs... and you may not even be aware of their existence.
The one that I have run into more than once is someone who used the MS Access Upsizing Wizard or from SQL just imported the tables into SQL out of the Access DB directly using the GUI. Then they wonder why it is a bloated mess. :pinch: By default, the text fields are created as NVarchar for an English only DB. You are essentially doubling the size of the data for no reason. What I'll generally do to make it easy is on me is use the upsizing wizard, script it out and then modify the script and re-import the data.
But there are so many things that I'll find a developer has done and ask "What in the h*** were they thinking?" I'm glad the development team is not within a couple of states of me. I'd be up on assault charges by now. :angry:
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
January 25, 2013 at 12:16 am
Jim P. (1/24/2013)
Nadrek (1/24/2013)
But there are so many things that I'll find a developer has done and ask "What in the h*** were they thinking?" I'm glad the development team is not within a couple of states of me. I'd be up on assault charges by now. :angry:
Same here, and exactly what triggered my original comments on the article; I once ran into an issue where a web application was running slowly and even timing out. It turned out that one of the queries in that web application needed about two records from the database, but read about 64GB worth of databasepages for that - on a 4Gb database (!). The issue started with the developers claiming we had not properly sized the database server... 😀
Cheers,
Rick
February 3, 2013 at 4:00 am
Not an expert here but wouldn't a corporation buying hardware to run a cloud platform crush a significant portion of the benefit? Not addressing data control concerns...
February 4, 2013 at 8:23 am
mhroche (2/3/2013)
Not an expert here but wouldn't a corporation buying hardware to run a cloud platform crush a significant portion of the benefit? Not addressing data control concerns...
Not necessarily. If a company does need to run a significant scale of machines, then it won't necessarily gain much benefit from a cloud provider. The other thing is that running in a cloud software area should dramatically reduce the amount of costs associated with administering the hardware. If developers and sysadmins don't have to configure/provision/manage individual machines, the cost goes way down.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply